I want to know that how can we know the IP address of client on server side in socket (java). Suppose there is a server "S" and 2 clients "A" and "B". Client A send me(server) some info, and Client B send me(server) some other info. I have to store that info coming from A and B in database in different tables. How can I Differentiate between client A and B request.?
Each socket has a getInetAddress() method which returns the IP address of the client connected to it.
The other answer has addressed your core question. I just want to add that there are some circumstances where the IP address you get back does not uniquely identify the true endpoint; i.e. the user's PC.
If two users are using the same system to connect; i.e. it is a multi-user system.
If the user's PC is behind a NAT gateway (because it has a private / site-local IP address), then the IP address you will get will be for the gateway.
It is also for the address to have been spoofed or hijacked in some way ...
There is nothing you can do to detect either of these situations from the server side. You just need to be aware of them, and not rely on the (supposed) client IP address as being definitive.
So ...
How can I Differentiate between client A and B request?
In any of the above circumstances, you cannot distinguish A and B by IP address alone. If you look at the connections to A and B while both connections are alive, they will have different remote port numbers. But those port numbers only last for the duration of the connection. However, next time A or B connects, A could be using the remote port that B was using, or vice versa.
Related
I want to simulate a network on my computer.
I want to send each packet with a different IP address.
How do I set the IP address on the Socket?
For example, I want to set my IP address is 192.168.1.1 or 192.168.1.1/24.
How do I do?
I only know how to set the port number.
private static DatagramSocket socket;
socket = new DatagramSocket(1024);
Can I use
DatagramSocket(int port, InetAddress laddr)
to initial my socket?
if yes, what should I input in the parameter "laddr"?
Assuming you mean set the source IP address - you can't. A UDP socket is bound to a particular IP interface (or interfaces) on your computer. The IP interface is what 'has' the address. A program using IP sockets only gets to choose which existing interface to use.
Note that even if you could arbitrarily set the source-address field in an outgoing datagram, there would be no simple way to receive any reply - because there's nothing on your computer responding to your chosen address (there is no IP interface at that address).
If you want to simulate having different IP addresses in a program,, you'll need to simulate IP. That would involve using raw sockets, but there does not seem to be a Java implementation for that.
I develop client-server application, working in real-time. Server and clients exchanges by small messages, so I choose UDP for my architecture (as suggested in many articles in network).
It's not a problem for me to use default java's DatagramSocket/DatagramPacket for orginizng all things as I want, but when I read documentation I see the "MulticastSocket" opportunity.
But it is completely unclear for me: How MutlicastSocket at the user side will know where to connect? (public IP/port of the server). Really, as this shown at this official java tutorial.
MulticastSocket creates like:
MulticastSocket socket = new MulticastSocket(4446);
InetAddress group = InetAddress.getByName("203.0.113.0");
socket.joinGroup(group);
and there is NO any specification about public server IP and port.
What is "203.0.113.0"? It is possibles that tones of applications send something to that address in web, isn't it?
When I create client in regular (not Multicast) way I use something like:
DatagramSocket outputClientSocket = new DatagramSocket();
DatagramPacket outputPacket = new DatagramPacket(new byte[512],512,InetAddress.getByName("94.***.89.***"),9898);
...
where "94.???.89.???" is my server's public IP address, and 9898 is port of my server, that listens it. Like that:
DatagramSocket serverInputSocket = new DatagramSocket(9898);
DatagramPacket inputServerPacket = new DatagramPacket(new byte[512],512);
serverInputSocket.recieve(inputServerPacket);
and after recieving something I can establish connection with client, and answer something for him, like that:
DatagramSocket socketForSpecificClient = new DatagramSocket();
InetAddress realClientAddress = inputServerPacket.getAddress();
int realClientPort = inputServerPacket.getPort();
DatagramPacket packetForSpecificClient = new DatagramPacket(new byte[512],512,realClientAddress,realClientPort);
socketForSpecificClient.send(packetForSpecificClient);
This approach works well, even if client has no public IP.
It is absolutely clear way of establishing connection for me, but I can't understand for what purposes MulticastSocket should be used?
Multicast is in IPv4 usually not working across network segments. If your application is supposed to work on the internet (and not e.g. just within an intranet under your control), you can not base your communcation on multicast.
Edit: Here are some further resources on the subject:
Wikipedia on IP multicast:
multicast services are generally not available to the average end-user
Other Stackoverflow question 'UDP Multicast over the internet?':
In general this is not possible since multicast packages aren't routed.
Discussion on hardforum.com 'Does multicast work over the itnernet(sic)?':
ISPs filter mutlicast you can't join a multicast stream over the internet.
These are just a few of the first hits when googling for 'using multicast over the internet'.
The address range 203.0.113.0/24 is reserved for use in 'documentation and example code' so the address in the example, 203.0.113.0, does not point to a real endpoint.
If you need a real, public multicast address and are connected through an ISP with multicast support, you have to obtain one from the IANA registry. You are right that anyone can send (potentially bogus) data to that IP address, but you have exactly the same problem with unicast addresses. If you provide a service on a unicast address, anyone can connect to that address and send data to it.
Quoting the paragraphs from the book Java Network Programming for framing the answer :
How MutlicastSocket at the user side will know where to connect?
(public IP/port of the server)?
What is "203.0.113.0"? It is possibles that tones of applications send
something to that address in web, isn't it?
Firstly, you should generally use IP-Address lying between 225.0.0.0 to 238.255.255.255 for creating a new multicast group.
When a host wants to send data to a multicast group, it puts that data in multicast datagrams, which are nothing more than UDP datagrams addressed to a multicast group. Multicast data is sent via UDP.
A multicast address is the shared address of a group of hosts called a multicast group. IPv4 multicast addresses are IP addresses in the CIDR group 224.0.0.0/4 (i.e., they range from 224.0.0.0 to 239.255.255.255).
A multicast group is a set of Internet hosts that share a multicast address. Any data sent to the multicast address is relayed to all the members of the group. Membership in a multicast group is open; hosts can enter or leave the group at any time. Groups can be either permanent or transient. The IANA is responsible for handing out permanent multicast addresses as needed.
Multicasting sends data from one host to many different hosts, but not to everyone; the data only goes to clients that have expressed an interest by joining a particular multicast group. In a way, this is like a public meeting. People can come and go as they please, leaving when the discussion no longer interests them. Before they arrive and after they have left, they don’t need to process the information at all: it just doesn’t reach them. On the Internet, such “public meetings” are best implemented using a multicast socket that sends a copy of the data to a location (or a group of locations) close to the parties that have declared an interest in the data.
In the best case, the data is duplicated only when it reaches the local network serving the interested clients: the data crosses the Internet only once. More realistically, several identical copies of the data traverse the Internet; but, by carefully choosing the points at which the streams are duplicated, the load on the network is minimized. The good
news is that programmers and network administrators aren’t responsible for choosing the points where the data is duplicated or even for sending multiple copies; the Internet’s routers handle all that.
To receive data that is being multicast from a remote site, first create a MulticastSocket with the MulticastSocket() constructor. As with other kinds of sockets, you need to know the port to listen on. This code fragment opens a MulticastSocket that listens on port 2300:
MulticastSocket ms = new MulticastSocket(2300);
Next, join a multicast group using the MulticastSocket ’s joinGroup() method:
InetAddress group = InetAddress.getByName("225.2.2.2");
ms.joinGroup(group);
This signals the routers in the path between you and the server to start sending data your way and tells the local host that it should pass you IP packets addressed to the multicast group.
Once you’ve joined the multicast group, you receive UDP data just as you would with a DatagramSocket .
It is possibles that tones of applications send something to that
address in web, isn't it?
One would face the same problem even in case of unicast communication if the address is known on which the service is provided.
I'm working on a ServerSocket with java, and I would like to know, upon a client connecting, is it possible to send the Client/Socket to another ServerSocket. For example a client connects to 123.41.67.817(Just a random IP) and upon connection, the client gets sent straight to for example 124.51.85.147(Another Random IP) with a port of course. So a little Map of what would happen.
ServerSocket(Listening for Connections)
Client ---> ServerSocket(Client connects)
ServerSocket -> Client(Server says: Hello, I am going to send you to 124.51.85.147)
Client -> ServerSocket(Client Says: OK!)
Client ---> ServerSocket(124.51.85.147)(Client gets sent to a different server Socket)
ServerSocket(124.51.85.147) -> Client(Server2 says: Welcome!) and then the client stays on Server2(124.51.85.147)
Is this possible in any way. Sorry for the long question.
Is this possible in any way.
No.
At the most basic level, a TCP/IP connection is a conversation between a pair of IP addresses. There is no provision in the TCP/IP protocol for changing one of the two IP addresses in mid conversation.
Even if it were possible at the Java level to (somehow) serialize the Socket object and send it to another program (local or remote), it would not be possible to change the IP addresses for the underlying conversation; see above.
Historical footnote: A long time ago (1980's) in a country far away (Cambridge UK) there was a network (The Cambridge Ring) whose stream protocol (BSP) implemented an operation known as "replug". If you had BSP connection between A & B and another between B & C, then B could replug the connections so that A talked directly to C. Reference: "The Cambridge Distributed Computer System" by R.M. Needham & A.J Herbert (Annex C).
I've never seen a replug operation elsewhere. Indeed, if you think about it, it requires a complicated 3-way handshake to implement a replug-like operation reliably. In the BSP case, they didn't do that ... at least according to the description in Needham & Herbert.
What would happen if change both clientSocket and serverSocket to “mySocket”?
Can the client send a segment to server without knowing the server’s IP address and/or port number?
Can multiple clients use the server?
From my notes, on page 20 : http://www.cs.ucc.ie/~cjs/teach/cs2505/02-app-layer-b.pdf . Kind of confused with these.
I assume if you change both client and serverSocket to mySocket then nothing would happen, since it would only be a variable name change( I assume ).
And I assume the client can't send a message without know the IP address/port no?
And that multiple clients cannot use the server since that would require threading?
(1) Since I see no reference to mySocket other than the one in the question I would say your answer seems right.
(2) The address/port are obviously necessary. However this could be a trick question in that client could call connect() on the socket. With UDP, connect() the kernel keeps track of the address passed in the call as the peer of the socket. The socket could then just call write() or send() rather than having to use sendto(). Still, calling connect would still require the address/port in the first place so who knows what they are getting at.
(3) There is no "connection" in UDP. Many clients could send to the server. The server can get the address of the individual clients from its recvfrom and then turn around and use that address in its sendto.
I'm writing a UDP server, which is a first for me; I've only done a bit of TCP communications. And I'm having trouble figuring out exactly how to distinguish which user is which, since UDP deals only with packets rather than connections and I therefore cannot tell exactly who I'm communicating with.
Here is pseudocode of my current server loop:
DatagramPacket p;
socket.receive(p); // now p contains the user's IP and port, and the data
int key = getKey(p);
if(key == 0) { // connection request
key = makeKey(p);
clients.add(key, p.ip);
send(p.ip, p.port, key); // give the user his key
} else { // user has a key
// verify key belongs to that IP address
// lookup the user's session data based on the key
// react to the packet in the context of the session
}
When designing this, I kept in mind these points:
Multiple users may exist on the same IP address, due to the presence of routers, therefore users must have a separate identification key.
Packets can be spoofed, so the key should be checked against its original IP address and ignored if a different IP tries to use the key.
The outbound port on the client side might change among packets.
Is that third assumption correct, or can I simply assume that one user = one IP+port combination? Is this commonly done, or should I continue to create a special key like I am currently doing?
I'm not completely clear on how TCP negotiates a connection so if you think I should model it off of TCP then please link me to a good tutorial or something on TCP's SYN/SYNACK/ACK mess.
Also note, I do have a provision to resend a key, if an IP sends a 0 and that IP already has a pending key; I omitted it to keep the snippet simple. I understand that UDP is not guaranteed to arrive, and I plan to add reliability to the main packet handling code later as well.
UDP packet headers have a source port, which is generally used as the reply port. If not used, it should be zero, and then it is up to the higher level protocol to figure out how to coordinate request-response activity with multiple clients.
* The outbound port on the client side might change among packets.
Is that third assumption correct
Not if the client keeps using the same outbound socket. Sending the first datagram will cause a local bind, so the socket will be on a fixed local port from then on.
Your questions are just the tip of the iceburg WRT laundry list of issues you need to be aware of when using UDP. You should expect NAT routers to fail to provide any meaningful forwarding of a UDP protocol you design. TCP works because the routers understand the TCP state machine and store connection state of each session so they know how to forward it. They will have no idea how your custom UDP protocol works. NAT devices include specific protocol handlers for well known UDP applications.
If a sender is bound to a source port and or interface the senders source ports remain constant until unbound.
With UDP you can bind both peers to a known source port for (dst) incoming and or (src) outgoing messages. For client/server applications you typically want the client to bind to a dynamic source port so that multiple clients can co-exist on a single client system. The server can then respond to the client using the dynamic source port provided via the src port from request used as destination port in the response. Using a known port for peers allows you to configure UDP forwarding in NAT devices.
ex client/server with server on known port 3000
client binds to a random port (1234) but knows server is listening on port 3000.
client (src 1234) -> server (dst 3000)
server (dst 1234) -> client (src 3000)
...
If a computer has multiple interfaces you should expect to either need to explicitly bind a listener or sender to a specific IP address or be able to handle requests and responses from a peer being sent and recieved from a random IP based on the whims of the computers routing table. If you choose to bind requests to a specific interface then you need to be cognizant of the routing table if messages from a multi-homed system need to transit a different local interface for delivery. For example if you bind a UDP socket to 127.0.0.1 you obviously can't use it to send to any Internet routable IP Addresss.
In terms of protocol design its common to frame a session id and sequence fields in the UDP payload so that peers can keep track of sessions and individual exchanges.
There are a whole host of fragmentation, NAT coexistance, security and congestion issues you need to be aware of to successfully design a robust UDP protocol. I advise against it unless absolutely necessary.