Re: so_rerror

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

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

| On 07/11/2018 12:31, Christos Zoulas wrote:
| > What concerns me is that the unit test t_sendrecv behaves differently
| > in the presence and absense of SO_RERROR and it should not.
| 
| In the presence of SO_RERROR there is an extra context switch to pump 
| the error to userland. Recall, I prompted you to make this change in 
| your patch. This effectively causes the receiver to overflow more often 
| in your test case because it has more work to do. If you revert my 
| suggestion and always wake up the socket, the chances are that you'll 
| see similar loss without SO_RERROR as well.

Could be the context switch, but I would expect the regular case to lose
as well (but more infrequently). Perhaps I need to stress the machine more
to see that.

| But fundamentally, the test case is flawed. UDP says packets can:
| 1) be discarded
| 2) arrive in a different order than what was sent
| This is basic UDP 101, but the test cases requires the complete opposite 
| of the above.

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...

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).

| On 06/11/2018 00:31, Christos Zoulas wrote:
|  > Yes and the prevailing opinion from others is that the "medium" should
|  > not affect the protocol behavior. I.e. UDP connections between two hosts
|  > and the same host should behave the same way.
| 
| We could argue the that SO_RERROR path is a different medium as it has 
| more work to do and when it's fully loaded it won't transmit as fast. 
| Like say a saturated wireless network.

I would say that this side-effect or SO_RERROR is unexpected (at least
to me).

| As such I contend that medium can and will affect protocol behaviour 
| with regards to the expectations of the receiver. Your test case and 
| expectation clearly demonstrates this given your knowledge and expertise 
| in UDP.

I understand the cause of out of order packets.  I did not write
this test to test SO_RERROR though; I added SO_ERROR to the test
because I was curious if there was a different behavior.

christos