using ipfw seems to interfere with socket communication

[Stefan Bethke]

Am 28.06.2006 um 00:13 schrieb Mikhail Teterin:

>     fconfigure $sock -blocking 0
>     lappend result c:[gets $sock]
>
> was always returning empty string, instead of the string "two",  
> that was
> written into the socket and flushed.
>
> Is the test wrong, and such result is possible, or is dummynet  
> triggering a
> bug? Unloading the dummynet module allows the test to succeed...

The test is wrong. See recvfrom(2), which the gets will eventually  
invoke:
      If no messages are available at the socket, the receive call  
waits for a
      message to arrive, unless the socket is nonblocking (see fcntl 
(2)) in
      which case the value -1 is returned and the external variable  
errno set
      to EAGAIN.

And Tcl gets(n):
        If  end  of  file occurs while scanning for an end of line,  
the command
        returns whatever input is available up to the end of  file.    
If  chan-
        nelId  is  in  nonblocking  mode  and there is not a full  
line of input
        available, the command returns an empty string and does not  
consume any
        input.  If varName is specified and an empty string is  
returned in var-
        Name because of end-of-file or because of  insufficient   
data  in  non-
        blocking  mode,  then  the return count is -1.  Note that if  
varName is
        not specified then the end-of-file and no-full-line-available  
cases can
        produce the same results as if there were an input line  
consisting only
        of the end-of-line character(s).

Essentially, dummynet delays processing of that "two" line just long  
enough to break the code's assumption that TCP over the loopback  
interface is instantaneous. If my fading memory of TCP/IP Illustrated  
Vol 2 serves me right, that was actually the case at least back then:  
the sendto system call would push the data all the way down to lo0,  
which would immediately pass it back up until it ended up in the  
receiving socket buffer.  Dummynet will queue the packet, regardless,  
so it won't get delivered until the next time dummynet processes queues.

In non-blocking mode, you must always be prepared to wait for data.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 170 346 0140