Re: AW: Still much more than 350 sockets needed!

["Wes Shull" <wes shull gmail com>]

On 4/27/06, Andrew Haley <aph 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