Re: so_rerror

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 8,  3:10am, roy%marples.name@localhost (Roy Marples) wrote:
-- Subject: Re: so_rerror

| > Yes, in this case AF_LOCAL can't arrive out of order. Even if I was
| > testing AF_INET{6,} on localhost (or on the same physical network segment)
| > it could not arrive out of order...
| 
| But it can because packets were discarded.

Discard does not change the order. A later packet can only arrive earlier
if there is a chance for the later packet to overtake the prior one. On
a FIFO there is no such chance.

| Without SO_RERROR, the receiver doens't context switch on error so it 
| looks like this:
| 
| # = send/recv
| * = overflow
| . = non op
| 
| sender    |##############*.....|
| receiver  |##############*.....|
| 
| But with SO_RERROR it looks like this
| 
| sender    |##############*.....|
| receiver  |##*###*##*####*.....|
| 
| So while you might send successfully in sequence, the receiver didn't.
| As discarded packets == out of order for this test case.

Out of order != missing. Out of order means packet (n + x) arriving
before (n). This cannot happen in this case.

I also don't see the receiver printing that the server overflowed
in the SO_RERROR case. Perhaps the test is flawed, but I would have
expected recv() to get ENOBUFS, and it does not.

| > In this test the sequence number is only incremented on successful send.
| > I expected AF_LOCAL to not drop packets in that case (and it did not).
| 
| Just because it was successfuly sent does not mean it was succesfully 
| recieved. And packets were dropped for AF_LOCAL otherwise it wouldn't 
| see any overflow errors, but yet it does (for SO_RERROR).

Yes, and this is one of the things the test is trying to validate:
That the stack is not dropping packets after they have been
successfully queued. This should be the case for AF_LOCAL packets.
It can be the case for packets on the wire though, of course.

| Maybe it's just me, but everything said thus far just solidifies my 
| position. But as I said earlier, I'm past caring. I can't make anyone 
| here understand and no-one has given a convincing enough argument that 
| I'm wrong.

I understand that you are upset about this, try not to be. As I
mentioned before I want to get to the bottom of this and find the
best solution for NetBSD. This is why I keep trying to understand
what's going on with the test, and I am planning (once I get some
more time) to run this on other network stacks to see how they
behave. The SO_RERROR paint is not dry yet; we just fixed another
issue with getsockopt(SO_ERROR) (it was not reporting SO_RERROR
before), and there are other minor issues here and there worth
undestanding.

christos