Re: Context of error messages with respect to BSD sockets

On Aug 9, 8:56 am, Rainer Weikusat <rweiku...@xxxxxxxxxxx> wrote:
Michael <Michael.Reil...@xxxxxxxxx> writes:
* EAGAIN or EWOULDBLOCK

under what circumstances will send or recv block? I'm not sure
exactly why I would recieve such an error

A 'connection mode' socket (eg TCP) usually has an in-kernel send and
receive buffer associated with it. recv will block if the receive
buffer is empty and send, if the send buffer is full (send basically
just copies the data from an application buffer into a kernel buffer,
the kernel transmits it asynchronously and removed acknowledged data
from the buffer). If the socket is configured for non-blocking I/O, an
I/O-call that would otherwise block returns with -1 and errno set to
EAGAIN.

* EBADF
What exactly constitutes a bad file descriptor? One that's not open,
one that has never been allocated for your process (whether its
currently open or not), or one that hasn't been allocated anywhere in
the system?

An integer which, at the time of the system call, does not correspond
with a valid 'file table entry' of the calling process.

Will handing it a file descriptor referring to a socket that has
closed cause an EBADF to be thrown?

UNIX(*) is a polite system and doesn't throw errors at you, it just
keeps them in a place where you may look at them if you care.

* ECONNRESET
For whatever reason, this signifies that the connection has closed
without the other side sending a close directive, ie timed out(as a
result of a system crash, for example). Is this correct?

Not exactly. For TCP, it means that, instead of acknowledging a
segment, the remote endpoint has sent a RST (ReSeT) back. This is
intended to inform the sender that there was no connection matching
the sent segment at the other host.

* EFAULT
The man page states "An invalid user space address was specified for
a parameter". Does this mean I've tried to hand it a pointer to data
outside of my process's address space?

Yes.

* EINTR
What's the general policy for recovering from this? just try
again?

EINTR is returned by some system calls if a signal was handled by the
process while it was blocked in the kernel. What to do then depends on
whose handler it was (yours or one installed by a library) and what it
is supposed to accomplish.

* EMSGSIZE
How do I know if the protocol is expecting send to happen
atomically,

Protocols preserving message boundaries (eg UDP) usually do.

[...]

* ENOBUFS
What's the general strategy for recovering from this? Just try again
later?

Presumably, this originated from BSD and was intended to inform the
application that no mbufs were available at the time of the call (any
details would be appreciated). Apart from that, yes.

* ENOMEM
Can this be recovered from, and if so, whats the best way to do so?

It's basically the same as the one above, just less specific wrt what
type of allocation failed, so, yes again.

* EPIPE
change the status of the socket to closed and go on with your life?

Or reconnect.

How does the resulting SIGPIPE affect things?

You will only get EPIPE if the disposition for SIGPIPE has been set to
'ignore'. The idea behind this is that a 'naive' program (one that
just writes to stdout) does not need to care if what is really
associated with that descriptor can become 'a broken pipe', while
programs knowing a little more about their environment can implement a
different behaviour.



Thank you for the response Rainer, I have one final question.

In the case of ECONNRESET or EPIPE, what is the expected behavior if
you were to do a select over those sockets if they haven't been closed
yet? Will you be able to detect a "disconnect" as per normal, or will
you need to take care of those details at the point the error is
caught?



.

Relevant Pages

  • Re: Context of error messages with respect to BSD sockets
    ... under what circumstances will send or recv block? ... A 'connection mode' socket usually has an in-kernel send and ... receive buffer associated with it. ... this signifies that the connection has closed ...
    (comp.unix.programmer)
  • RE: Does Socket.Shutdown or Socket.Close Block and when?
    ... keeps trying to send the data in the send buffers of the socket until TCP ... in the send buffer has been sent or the timeout has elapsed. ... > connection is still up to each client). ... > heartbeat within say 10 seconds then the server will proceed to shutdown the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Socket BeginSend and disconnections
    ... What determines the length of time between this remote user yanking his ... It does depend somewhat on how the connection is broken and where. ... In theory, you should be able to queue as many sends as you need, especially if you've set the socket buffer itself to 0 ). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Coordinating TCP projects
    ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... Jim and I recently discussed the idea of implementing autotuning of the TCP reassembly queue size based on analysis of some experimental work we've been doing. ... This means that if the TCP window grows to be more than 48 segments wide, and a packet is lost, the receiver will buffer the next 48 segments in the reassembly queue and subsequently drop all the remaining segments in the window because the reassembly buffer is full i.e. 1 packet loss in the network can equate to many packet losses at the receiver because of insufficient buffering. ... We observed that the socket receive buffer size provides a good indication of the expected number of bytes in flight for a connection, and can therefore serve as the figure to base the size of the reassembly queue on. ...
    (freebsd-arch)
  • Re: Coordinating TCP projects
    ... It is rapidly becoming clear that quite a few of us have Big Plans for the TCP implementation over the next 12-18 months. ... Jim and I recently discussed the idea of implementing autotuning of the TCP reassembly queue size based on analysis of some experimental work we've been doing. ... This means that if the TCP window grows to be more than 48 segments wide, and a packet is lost, the receiver will buffer the next 48 segments in the reassembly queue and subsequently drop all the remaining segments in the window because the reassembly buffer is full i.e. 1 packet loss in the network can equate to many packet losses at the receiver because of insufficient buffering. ... We observed that the socket receive buffer size provides a good indication of the expected number of bytes in flight for a connection, and can therefore serve as the figure to base the size of the reassembly queue on. ...
    (freebsd-net)