UDP select()/recvfrom() delay under Windows?

[David Holroyd]

I have the following snippet of code in a UDP client I'm knocking
together:

def await_packet(timeout)
packet = @recv_queue.shift
return packet unless packet.nil?
read_fds = [@sock]
mylog("selecting..")
return nil unless (fds = select(read_fds, nil, nil, timeout))
selected_read_fds, selected_write_fds, selected_error_fds = fds
return nil unless selected_read_fds.include?(@sock)
mylog("recvfroming..")
data, from = @sock.recvfrom(MAX_SIZE)
mylog("..done recvfroming")
frame = NA::read_server_frame(ReadBuffer.new(data))
# TODO: filter stray ACKs?
frame
end


When I run my test code in ruby 1.8.2 (2004-12-25) [i386-mswin32], I
see, for example:

C:\na>ruby -w client_test.rb
1116865503.777 NA:honeSocket: selecting..
1116865503.777 NA:honeSocket: recvfroming..
1116865518.769 NA:honeSocket: ..done recvfroming
1116865518.779 NA:honeSocket: selecting..
1116865518.779 NA:honeSocket: recvfroming..
1116865538.287 NA:honeSocket: ..done recvfroming

I notice that there is a gap of some several seconds between select()
completing, and recvfrom() completing -- I expected that, since select()
reports data can be read, recvfrom() should not block. Am I wrong?

Also, I am fairly confident that there *is* data that could be read
immediately, as I can see packets arriving (in Ethereal, running on the
same machine as the above Ruby code).


Any help (even a reply that this is off-topic, and that I don't
understand socket programming) much appreciated.

dave

 

[Ville Mattila]

When I run my test code in ruby 1.8.2 (2004-12-25) [i386-mswin32], I
see, for example:


I notice that there is a gap of some several seconds between select()
completing, and recvfrom() completing -- I expected that, since select()
reports data can be read, recvfrom() should not block. Am I wrong?

Also, I am fairly confident that there *is* data that could be read
immediately, as I can see packets arriving (in Ethereal, running on the
same machine as the above Ruby code).


Any help (even a reply that this is off-topic, and that I don't
understand socket programming) much appreciated.

I think this will be fixed in 1.8.3 so you could try it. There is a 1.8.3rc1
available at www.ruby-lang.org. You have to compile it your self though.

- Ville

 

[David Holroyd]

When I run my test code in ruby 1.8.2 (2004-12-25) [i386-mswin32], I
see, for example:


I notice that there is a gap of some several seconds between select()
completing, and recvfrom() completing -- I expected that, since select()
reports data can be read, recvfrom() should not block. Am I wrong?

I think this will be fixed in 1.8.3 so you could try it. There is a 1.8.3rc1
available at www.ruby-lang.org. You have to compile it your self though.

I don't have MSVC++, so I downloaded ruby-1.8.3-preview1-i386-mswin32.zip
from http://www.garbagecollect.jp/ruby/mswin32/en/download/release.html
and unpacked that over the top of the install directory created by
ruby182-15.exe.

Using ruby 1.8.3 (2005-05-12) [i386-mswin32], I still see recvfrom()
block for 4-5 seconds each time it's called.

Oddly, when I access the server off-site, using a tunnel, there's no
delay (i.e. when the Ruby program is configured to connect to the tunnel
endpoint on localhost, rather than directly to the server machine).


dave

 

[David Holroyd]

Using ruby 1.8.3 (2005-05-12) [i386-mswin32], I still see recvfrom()
block for 4-5 seconds each time it's called.

Oddly, when I access the server off-site, using a tunnel, there's no
delay (i.e. when the Ruby program is configured to connect to the tunnel
endpoint on localhost, rather than directly to the server machine).

Thanks to the suggestion of Kent Sibilev in...

http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/143546

...my app is now running much faster. Yay!


dave