why socket on the receiving peer keep receiving &#

问题:

I'm a newbie to socket programming, I know it's a bad habit to close socket using "control-c", but why socket on the receiving peer keeps receiving '' infinitely after I use "control-c" to close the sending process? shouldn't the socket on the sending peer be closed after "control-c" to exit the process? Thanks!

回答1:

I know it's a bad habit to close socket using "control-c"

That closes the entire process, not just a socket.

why socket on the receiving peer keeps receiving '' infinitely after I use "control-c" to close the sending process?

At a guess, which is all that is possible without seeing the code you should have posted in your question, you are ignoring errors and end-of-stream when calling recv().

shouldn't the socket on the sending peer be closed after "control-c" to exit the process?

It is. The whole process is 'closed', including all its resources.

As regards the receiving socket, it is up to you to detect the conditions under which it should be close, and close it.

回答2:

No code given, but here's an educated guess of what might be going on:

1. You have two separate bits of code running: Sending and receiving
2. You are in the process of transferring data when you use CTL+C to kill the sending socket.
3. You expect the receiving socket to stop, but it doesn't.

The issue could be one of "end of transmission" agreement. If the sending code fires off an End-of-File (EOF) (or abort or terminated) when you hit CTL+C, then the receiving socket should see that and quit receiving. However, you haven't stated what the sending code is doing the moment you hit CTL+C.

The receiving socket may just be waiting for more data; as far as the receiving code is concerned, it was to be told when transfer is done, and it is patiently waiting for more information.

There are far better socket programmers around than I am, but I think it's safe to say that, once you get down to that level, you should pay attention to the details of the transfer protocol. If CTL+C just terminates the server (sending) code, then the client has no idea if there is a real termination, an unexpected delay in the transmission, or the server process just had a brain-fart and will start sending again once things clear up.

If you have any means of monitoring the actual values going back an forth, take a look at what happens during a "normal" termination of data transfer and a CTL+C termination. This might help you zero in on the undesirable behavior.