Some questions around sockets and accept()

Question

Lets say that we have created a socket with socket(), then we used bind() and listen(). Then we use accept() to wait for client requests, after a client is connected if we shutdown the server (for example we ctrl+c the process).

Is the client still connected to the port ?
Can we somehow reestablish connection to the socket ?
Is this a client-side issue as well ? Or does recvfrom() wait for someone to bind back to the socket ?

score 3 · Accepted Answer · edited Jun 20 '20 at 09:12

3

I am going to assume you're using TCP.

If we shutdown the server:

Is the client still connected to the port?

No. The operating system on the server side will have noticed that the server terminated, and will have closed the connection, sending a packet to the client which ends the connection. Even if this does not happen (e.g. the network fails), the connection is no longer usable, and the first time the client sends something, it will realize the connection was lost. Some programs use TCP Keep-Alive or send heartbeat messages to make sure they notice if the server goes away.
Can we somehow reestablish connection to the socket?

No. The client needs to establish a new connection.
Is this a client-side issue as well? Or does recvfrom() wait for someone to bind back to the socket?

recvfrom() does not wait in such a way. The server cannot "reconnect" or "rebind" in the way you are implying. The client will need to respond to the disconnection by explicitly reconnecting.

edited Jun 20 '20 at 09:12

Community

1
1

answered Feb 05 '17 at 01:13

John Zwinck

239,568
38
324
436

He is using `listen()` and `accept()`. No assumption necessary. – user207421 Feb 05 '17 at 01:24
2

Thank you for the information and the time you spent answering. – Naoum Mandrelas Feb 05 '17 at 01:24
@EJP: OP might be using SCTP for example: https://linux.die.net/man/7/sctp - it uses the same functions as TCP. Obviously TCP is most likely, but it is indeed an assumption. – John Zwinck Feb 05 '17 at 01:30
OK, so if he was using SCTP how would your answer change? *Would* it change? – user207421 Feb 05 '17 at 01:37
@EJP: SCTP has keep-alive enabled by default, which TCP does not. SCTP also has multipath, in which case losing a single connection might not require the application to do anything. – John Zwinck Feb 05 '17 at 01:39
He has lost the entire server, not just a single connection. You haven't mentioned anything that would change your answer AFAICS. – user207421 Feb 05 '17 at 01:40
@EJP: This is really a huge digression. Feel free to just edit my answer if you like. – John Zwinck Feb 05 '17 at 01:41
I'm asking because I want to know, not to just argue with you. – user207421 Feb 05 '17 at 01:42

user207421 · Answer 2 · 2017-02-05T01:22:20.857

2

Is the client still connected to the port?

The client will get a connection reset when reading on Windows, or an EOS when reading under *nix, or a connection reset when writing.

Can we somehow reestablish connection to the socket?

To the port. The client can try to reconnect, but it won't succeed until the server is running and listening. The server can't do anything about it after it restarts.

Is this a client a client-side issue as well?

Yes, see above.

Or does recvfrom() wait for someone to bind back to the socket?

Certainly not.

NB You should be using recv() for stream sockets. You don't need the source-address information recvfrom() gives you, if indeed it does, because it's already available via getpeername() on the socket.

edited Feb 05 '17 at 01:22

answered Feb 05 '17 at 01:14

user207421

305,947
44
307
483

3

Thanks a lot for the time you spent answering and the information you provided – Naoum Mandrelas Feb 05 '17 at 01:25
2

@MakisMandrelas Thank you for your thanks. It is rare to get them here, unfortunately, and even rarer for anybody to acknowledge the time that responders take to answer. Your courtesy to both John and me is much appreciated. – user207421 Feb 05 '17 at 01:37

Some questions around sockets and accept()

2 Answers2