On Mon, 13 Aug 2001, Lex Spoon wrote:

>
> > One of the requirements of it is to handle large numbers of concurrent
> > socket connections and also handle incoming data securily to be immune
> > from DoS. By large number, I mean 50-500. Thus, busywaiting will be
> > deadly.
> >
>
>
> This isn't as much of a problem as you might expect, so give it a try
> before you do something complicated!  Many people disagree with me, so
> let me spell it out this argument once more, with numbers this time.
> Incidentally, it applies to user interfaces just as much as to network
> code.

Ok... You've convinced me of my sin. :) The deadly sin of premature
optimization, though its not quite as easy as you have it here.

You only cover the input side of things, but the output side is almost as
important. I'd like to have my code block on the sockets, rather than
busywait because I don't want the UI slowdown and squeak always using 100%
CPU and slow the rest of the machine down.

> Those arguments aside, here are the numbers.  I just checked, and my
> modest 366 MHz computer can do 95,000 #dataAvailable's per second on a
> socket that is open but idle.  That's 95 checks per millisecond, and 950
> times as fast as the 10 millisecond threshold mentioned above.  Thus, on
> a completely idle system, you check 950 sockets 100 times per second.

These numbers are superb; I hadn't realized they were quite this good..
But at, say, 1-3 commands/sec/socket, say, 500 sockets polled at 10ms,
thats 50,000 polls/sec, of which only about 500-1500 will have any data.
So, I'm spending about half of that CPU polling, and half constructing a
Then add in the time and polling for output.. :/

Yeah, it probably doesn't matter too much, Expecting 500 users is
impractical, but I would like a framework I was confortable with.  Where I
block on no network input to not use 100% of the time. Some sort of
'socketpoll' object, which lets me mark a set of sockets I'm interested in
IO from, and it will wake up when any of them is ready and run a selector
of my choice.


>
> >
> > My problem:
> >    I can't get the reader process to block. If I use
> >   Socket>>waitForDataUntil: (Socket deadlineSecs: 60)
>
> This will wait for 60 seconds, but it really should return early if data
> arrives.  Can you make a small example that causes this problem?
>

I can describe what circumstances it happens:

run basically a

  [
     Socket>>waitForDataUntil: (Socket deadlineSecs: 60).
     Transcript show: 'output'
     true. ] whileTrue

Then, I send a line of text in. Socket>>waitForDataUntil returns
immediately with the text. Then remove all the text:
  ``primSocket: socketHandle receiveDataInto: buf startingAt: 1 count: buf size.''

Now wait a second or so.

Send another line of text.

The Socket>>waitForDataUntil: does NOT return immeditely, but waits out
 the remaining 60 seconds.

--

But it seems like squeak implements this waitForDataUntil internally as
being a busywait loop anyways.. Oh well.



> You don't even need the message queue, really -- just go ahead and
> handle the message!
>

Much much simpler. I like it. :)  Though I would like a version where I
could block on a 'socketpoll' command. :/

> In fact, after reading all of this, maybe just using StringSocket is
> sounding like a reasonable approach.

I'll check it out, now if only it had documentation..


Thanks for the insights, What I have now is fairly independent and could
be upgraded to this technique at some later time. But I'd like to bounce
ideas off of you later.. I like the beauty of the smalltalk language, but
I'm not yet experienced in 'the squeak way' as you are. Thanks!


Scott