At 11:14 AM -0500 11/15/99, Lex Spoon wrote:

>Bijan Parsia <bparsia at email.unc.edu> wrote:
[snip]
>
>No, but you just said "simultaneous" requests, so it wasn't clear what
>you meant.

You're right. Sorry 'bout that.

>  The more specific feature you describe is indeed important
>on a busy server.
>
>However, the necessary primitive for it is now in; one just needs to
>lobby some Mac programmer or another to try and implement it.

Oh, I been a lobbying :)

>  (It looks
>like this is happening).  And incidentally, minnow has an unrelated
>problem lately: it seems to have decided that 4 sockets are enough for
>anyone.  This is odd, because other Mac servers will allow many more
>connections to be open at once.

I'll note that I spent some time trying to duplicate Minnow's problems and
observed weird socket accumulations and slow socket "dispersals" with
various configuration.

I'm unclear when a server should "stop" accepting connections and how it
should behave then. In some documentation I've read, 8 slots in the
connection queue is held to be standard and that it might be a bad idea to
have more, but I also read that Netscape's server had 1024! slots in its
queue. I know I'm confused :) It strikes me that this is something that
should be in the primatives, if we're to make use of the OSs queue  (which
is different, I take it, than Squeak's ConnectionQueue...or something ;). I
could look this up, yet again :)

>
>[ networking is unstable on Bijan's Macs ]

(Actually, it's often unstable on my PCs ;) I'm finally feeling confident
enought to try to latest VMs across the board.)

>Ahhh, you've been seeing a lot of crashes.  That's not good.  Have you
>tried hashing out what went wrong over on the pws list?  Perhaps
>ConnectionQueue was running out of sockets and busy looping.  We (Tech
>squeakers) have a patch that keeps this from becoming a hard crash, if
>this is the problem.  Hopefully this patch becomes a squeak default
>eventually.

Well, at the moment I'm not running any servers very hard at all. So I'm
not seeing any crashes :)

[snip]

>The biggest stability bugs we've found at GT have been in dealing with
>the situation where sockets have run out.  The second biggest problem is
>in the way sockets are shut down; TCP is picky about how it's down, and
>if you do it wrong, the connection will get aborted early.  We've done a lot
>of beating on Squeak networking, and not seen a need for any primitives
>other than the listenOn:backlog: one that got added recently.

Hmm. I'm not sure how that one is supposed to work, and how it helps, etc.
Pointer?

Cheers,
Bijan Parsia.