AW: Still much more than 350 sockets needed!
Wes Shull
wes.shull at gmail.com
Thu Apr 27 20:37:34 UTC 2006
On 4/27/06, Andrew Haley <aph at redhat.com> wrote:
> It works for me, bouncing data back and forth. What does it do on
> your box? What is the output?
unadultered output at http://kuoi.asui.uidaho.edu/~wes/out.txt ; here
is an abbreviated annotated version:
Creating listener on 3000
Connecting to listener on 127.0.0.1:3000
[...]
Creating listener on 3499
Connecting to listener on 127.0.0.1:3499
I'm doing the connect asynchronously so all this really says it that
it's not hitting the file descriptor limit...
client: 3499<-marco
server: 3499 accepted
[...]
client: 3482<-marco
server: 3482 accepted
18 of the connections are made and the server side sees the data, but...
client: 3481<-marco
[...]
client: 3000<-marco
The other 500-18 connections are never accepted. Tcl channels also go
writable on error (and I just realized my code doesn't check for that)
so it's probable it shouldn't even have been trying to send on these
because they never connected.
client_readable: 3000 went away
[...]
client_readable: 3481 went away
Here the client side catches that the other 500-18 connections didn't make it
server: 3482<-marco
[...]
server: 3499<-marco
server: 3499->polo
[...]
server: 3482->polo
client: 3482->polo
[...]
client: 3499->polo
client: 3499<-marco
[...]
client: 3482<-marco
These last four sequences continue ad infinitum; it's successfully
passing data back and forth, but only on those 18 connections.
Just for S&G, I ran this on a FreeBSD 6.0-RELEASE-p4 system, and while
it doesn't behave exactly the same, it didn't do what I expected there
either. Just to make sure I'm not running into some issue with
different Tcl builds (limited event queue length, limited # of active
connections), I'll rewrite this in C (bleah) tonight and see if it
behaves any better.
--wes
More information about the devel
mailing list