0

Sockets can generally two way communicate, therefore the same socket can be used to send and recv.
If I wanted to send some data (on another thread) while the socket is getting read, what would the kernel do? This is applied for both parts.

Consider this example: the server is sending you a file and say it will take a lot (low uplink or a very big file). The user gets bored and decides to SIGINT you. You catch it and tell the server to stop sending the file (with some kind of message).
Will you be able to send to tell the server to stop sending even though you're reading from it? And of course, that's applied to the server-side as well.

Hopefully I've been enough clear.

edmz
  • 8,220
  • 2
  • 26
  • 45
  • 4
    Duplex communication allows both sending and receiving at the same time... Also if you weren't able to inform the server that your socket is closed, it would cause a massive hang. – Bartek Banachewicz Mar 07 '14 at 13:52
  • Well I would say that you read and write with different process (fork()) and different pipes so I dont see the problem? Tell me if I'm wrong –  Mar 07 '14 at 13:53
  • @Mayerz you're wrong. – Bartek Banachewicz Mar 07 '14 at 13:53
  • Yhea i realized this when i saw your first comment, my bad. –  Mar 07 '14 at 13:54
  • I don't think you've figured correctly out my question, @BartekBanachewicz. I know you can both read and write to a socket. I am basically asking whether you can `send` (separately) while the main process is reading from it. Look at the example to get a clearer idea. – edmz Mar 07 '14 at 13:57
  • @black - yes, you can, as described by Banan.. Mr. Banachewicz. – Martin James Mar 07 '14 at 14:44

2 Answers2

1

Thread 1 can safely write to the socket (with send) whilst thread 2 reads from the socket (with recv). What you need to be careful of is that at the point where you close() the socket the threads are synchronised, else the file descriptor may be used elsewhere, so the other thread (if not synchronized) could read from a file descriptor now used for something else. One way to achieve this would be for your reading thread to shutdown the file descriptor, which should cause the other end to drop the connection and thus error an in-progress send.

abligh
  • 24,573
  • 4
  • 47
  • 84
1

If I wanted to send some data (on another thread) while the socket is getting read, what would the kernel do?

Nothing special... sockets aren't like garden hoses... there's just some meta-data added to a packet that's sent between the machines, so the reading and writing happen independently (apart perhaps from if one side calls recv() on a socket that has unsent data in the local buffers due to the Nagle algorithm, which bunches up data into sensible size packets, it might time-out immediately and send whatever it can, but any tuning of that would be an implementation latency-tuning detail and doesn't change the big picture or way the client and server call the TCP API).

Consider this example: the server is sending you a file and say it will take a lot (low uplink or a very big file). The user gets bored and decides to SIGINT you. You catch it and tell the server to stop sending the file (with some kind of message). Will you be able to send to tell the server to stop sending even though you're reading from it? And of course, that's applied to the server-side as well.

The kernel accepts a limited amount of data to be sent, and a limited amount of data received, after which it forces the sending side to wait until some has been consumed before sending more. So, if you've sent data to a server, then get a local SIGINT and send a "oh, cancel that" in the same way, the server must read all the already-sent data before it can see the "oh, cancel that". If instead of sending it "in the same way" you turn on the Out Of Band (OOB) flag while sending the cancel message, then the server can (if it's written to do so) detect that there's OOB data and read it before it's completed reading/processing the other data. It will still need to read and discard whatever in-band data you've already sent, but the flow control / buffering mentioned above means that should be a manageable amount - far less than your file size might be. Throughout all this, whatever you want to recv or the server sends is independent and unaffected by the large client->server send, any OOB data etc..

There's a discussion and example code from GNU at http://www.gnu.org/software/libc/manual/html_node/Out_002dof_002dBand-Data.html

Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
  • @black No. Would you prefer to have two phones when you called someone? You just need to write the code and see it working and stop worrying! ;-) – Tony Delroy Mar 07 '14 at 15:06