In socket programming, I see that the server is bind to an address- comprising of IP and port number. Then the steps are listen, and accept ( blocking call). I am wondering why the client doesn't need to bind with its ip address and port number. In fact, it binds with the server socket address. Afterwards, the client calls the connect() call to establish a connection. Later, client and server both can speak to each other. How a server can speak to the client? The client has not bind with its IP address and port number. How is it possible for a server to reach client?
Asked
Active
Viewed 1.2k times
3 Answers
16
I am wondering why the client doesn't need to bind with its ip address and port number.
Because there is an internal bind() as part of connect(), if the socket isn't already bound, and because the server doesn't care what the client's port number is: it doesn't need to be fixed like the server's port number.
In fact, it binds with the server socket address.
No it doesn't: it connects to the server's address.
How a server can speak to the client?
Over the connection that has been established.
The client has not bind with its IP address and port number.
Yes it has, see above.
How is it possible for a server to reach client?
Same way the client reaches the server. By sending a packet with a target address and port.
user207421
- 305,947
- 44
- 307
- 483
11
Choosing the client port number is usually done by the kernel. This makes sense as only the kernel knows which ports are currently in use. However, you are free to specify the client port on your own, but I think it is hard for client program to make sure the port is free. It could just "try an error"
Choosing the clients IP address is also usually done by the kernel, by consulting the IP routing tables. You can show and modify them using the route command.
You've asked how the server can know the clients IP address. You need to understand TCP/IP in order to answer your question. Read the wiki article. It should be a good starting point.
-
Question is how Server knows the client address to speak. – dexterous Feb 08 '14 at 13:58
-
You need to understand TCP – hek2mgl Feb 08 '14 at 13:59
-
OOh so , you are saying the packets - have src and destination address. From this it knows the destination. – dexterous Feb 08 '14 at 14:01
-
yes, that's what TCP/IP does :) (in fact TCP does more, it ensures that the packages reaches their recipients.) But UDP/IP is exactly just doing what you are asking. – hek2mgl Feb 08 '14 at 14:02
-
If clients IP address is also usually done by the kernel, then why not for Server side. Why binding and all for the Server side? Kernel can do the same for the Server also right? – dexterous Feb 08 '14 at 15:50
-
No, if you have multiple network interfaces you need to kernel which one(s) should the service be available on. This is the current implementation in Linux.. And I guess this is also POSIX standard. – hek2mgl Feb 08 '14 at 16:49
-
@hek2mgl, *"This makes sense as only the kernel knows which ports are currently in use"* Is there no kernel in the context of the server? If not then why the server gets to choose which IP address to bind to? – Mehdi Charife Nov 20 '22 at 18:09
-1
It's because client always have to connect to the server. Client can be called as slave and server is always the master. But server can speak to the client only if there is the particular code given such Buffered Inputstream. other wise it can't send any input to client even if there is a connection. Port number is basically the address of the program stored in the server computer. so when the program in client side has to contact server side it needs port number so server side doesn't needs client's port number as the client program itself wants to access server program.
sam
- 83
- 1
- 7
-
The server *can* 'speak to the client', *because* there is a connection. 'Particular code such as BufferedReader' has nothing to do with it. This answer is non-explanatory nonsense, apart from the parts that are just plain wrong. -1 – user207421 Feb 08 '14 at 23:50
-
The code in the server for communicating with the client is identical to the code in the client for communicating with the server. In both cases an output stream or writer is required. There is nothing different about the server-to-client direction. And don't lecture me about when to think. Stick to the topic and avoid the personal remarks. – user207421 Feb 09 '14 at 06:51
-
You haven't answered the question why the client doesn't have to bind; your statements that the server can't 'speak to the client' and 'can't send any input to the client' are both incorrect and irrelevant; I am not 'too quick' to judge these matters; and telling me what and when to think isn't on topic. The only thing you are correct about here is that I have downvoted your answer. – user207421 Feb 09 '14 at 08:23
-
Saying that the client needs to connect to the server doesn't answer the question why the client doesn't need to bind. Period. Have a look at the other answers to see what a real answer looks like. The rest of this nonsense is just irrelevant. – user207421 Feb 09 '14 at 09:06
-
Your answer states, and I quote, 'it's because client always have to connect to the server'. You do need to see the other answers, because your answer indicates imperfect knowledge of the topic. And don't make personal remarks here. – user207421 Feb 09 '14 at 09:39
-
By quoting just the first line, you are doing nothing but justifying yourself. Have you read the whole answer? It doesn't mean at all to what you are stating it to be. And regarding personal remarks, man practice before you preach! – sam Feb 09 '14 at 13:22
-
By quoting the first line I am exhibiting the statement in your answer that purports to answer the question and doesn't. Denying that you said it, and then deleting the denial, and then trying to start an irrelevant discussion about why I quoted it, doesn't address the issue. – user207421 Feb 09 '14 at 22:33