[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New class of receive error
Date: Sun, 13 May 2018 15:01:42 +0100
From: Roy Marples <roy%marples.name@localhost>
| Other OS's document ENOBUFS on recv calls.
That other OS's (by which I assume you mean linux) are broken is no reason
that we should be too.
Datagram protoctols inherently lose packets - aside from in this one very
special case, there's no way at the network level to inform the receiver of
a lost packet, as there's no way to know one was ever sent. The application
level needs to recover using its own mechanism - which could be using sequence
numbers in the packets as Christos suggested - but here I do not think can
work, as the messages come from a variety of sources (including other
processes) and there's no way to synchronise the (current) sequece numbers
But we could add a kernel geneerated seq number - set whenever a routing
packet is generated, and delivered to the receiver - that at least would be a
application layer recovery mechanism.
Aside from dhcpcd every instance of "handling" this error is to (at most)
log it and ignore it - it really is pointless.
The routing socket is something special - it arguably should not be using the
socket interface at all - as it is puerly a local host communication mechanism,
so the local host OS knows when a packet is sent, and when one is received,
and when one is lost, and so can (reliably) inform the receiver that a packet
has been lost - but that one is a very special case (along with the mobile IP
socket, which is just the routing socket with a different name (and purpose)).
My overall opinion is that if this message is not made opt-in (whatever the
default is set to for routing sockets) then the whole mechanism should simply
Main Index |
Thread Index |