Can a Client pushing data through a UNIX domain socket ( AF_UNIX type ) be signaled busy if the receiving end cannot cope with the load?
OR
Must there be a Client-Server protocol on top of the socket to handle flow control?
A:
Other than the server having some knowledge of when it is 'busy' and sending a specific signal back (e.g. HTTP's 503 Service Unavailable). You can also set up the client side connection to timeout after a certain length of time, and if you get a timeout event, interpret that as the server is busy.
AlBlue
2009-09-25 18:59:28
... and this behavior is generic to sockets in general *or* specific to AF_INET? (I am asking because of your example using HTTP)
jldupont
2009-09-25 19:02:58
PS the ETIMEDOUT is what you'd get from the socket 'connect' call if it wasn't able to make a connection within the given timeout time; setsockopt SO_SNDTIMEO with a time is the way you'd configure that (if you didn't want the default).
AlBlue
2009-09-25 19:04:03
Then again, the host might actually be down. Having your client sit in this sort of state is very misleading to those monitoring the process. (assuming it's mission critical)
windfinder
2009-09-25 19:04:10
+4
A:
Unless you include this in the protocol, there is no way for the server to tell the client to pause sending the information.
David Harris
2009-09-25 19:04:15
So in effect sockets are FIFO with no flow-control: an upper-layer protocol is needed for flow-control (if required).
jldupont
2009-09-25 19:07:48
TCP/IP doesn't know too much. Writing a handler for control messages (you have to write these too) is the only way to do this.
windfinder
2009-09-25 19:14:49
@Jean-Lou: that is correct. `AF_UNIX` provides absolutely no flow control semantics. The underlying device may provide buffer overflow conditions that will result in `send()` returning an error but that is device specific.
D.Shawley
2009-09-25 19:42:31