Re: productivity?

Peter J. Holzer wrote:
> I don't see how this can make a difference. TIME_WAIT is 240 seconds
> (per RFC, some implementations use shorter defaults). If your ephemeral
> ports are limited to the range 1024-4999 (which used to be popular), you
> are limited to (5000-1024)/240 = 16.6 connections per second. Putting in
> a sleep(0) doesn't change this, lowering TIME_WAIT or extending the
> range of ephemeral ports does. (Waiting for the other side to close the
> connection does, too - but unless I'm missing something moving the
> problem to the other side doesn't help if you want to communicate with
> the other side). I'm with Carl here - if you need to send 17+ mails per
> second, it's much better to reuse connections than to permanently close
> and reopen them.
Devil details.

I mentioned the poor man's poke because I seen it too often when a 
port to windows is done and it WINTEL fundamentals are not very well 
understood.  You got hardware interrupts (networking and disk) 
services where bottlenecks occur and other worker threads to cooperate 
with, so poking as a poor man's way to wake up other workers without 
losing must of your own time. Its not the 100% Wintel Way, but it can 
used. I might use it to help wake up hardware related concepts. 
Timing is everything, yet it needs to be understood how it can give 
you unpredictability.  Windows is not an RTOS (Real Time Operating 
System) where such timing predictions are guaranteed.   For example, 
it is often misunderstand what the actually elapse time are.
      Sleep(0)  15 ms,  return immediately
      Sleep(1)  15 ms,  Thread is Queued
      Sleep(21) 20 ms,  Thread is Queued
      Sleep(36) 45 ms,  Thread is Queued

etc, in other words for robust well understood system, you must have a 
understanding the CPU Quantum size and the whole timing paradigm under 
Windows. I have seen huge huge monster debates when unix thinking 
simply doesn't apply in Windows because they thought there was a 1 ms 
resolution with timing, they get hung on on Linux or other *nix timing 
slicing granularity (1ms vs 15ms) and believe that it equally applies 
to Windows - it doesn't and those that continue to think so continue 
to have problems or just live what they have achieved.
16.6 cps is very slow.

Was ASYNC or SYNCH used?  Threads?  Sequential programming?  You can 
blast 16 threads and you can't use reuseability.  You also need to 
take in account that Windows also have caching too.  So opening and 
closing is not as wasteful as you think.
As I noted to Carl off list, I just did a quick test using our 
internal SmtpStress tool that can blasting X threads with Y messages 
per thread, and without changing the license limit of 25 concurrent 
connections on our SMTP server test machine, I was able to blast 25 
message under 1 second. It wasn't even a full second.  Changing our 
logs to microseconds was all part of this profiling done early this 
year.  And I know more connections were possible because using X=50, 
there were a 25 421 server responses.
Note: That is another thing in RFC5321, it doesn't explicitly say that 
421 can be used at the connection point. It mentions 554, but that 
requires you to hold the connection until the client issues a QUIT.
Finally, I do think, what you touched base with, a half-close shutdown 
needs to be check if this is needed.  Why?  Because when the 
Download/Upload speeds differences became dramatic, all of a sudden 
applications such as IE, Apache and so many others, including our own 
Wildcat! Web Server began to experience timing and synchronizations 
problems.  The infamous IE "Page Not Found" problem was directly 
related to servers not using Half-Close socket Shutdown.  It was all 
because the of that final ACK was lost. I specially recall reluctantly 
trying Sleeps() to try to get it to work, but what worked here, didn't 
work there. The solution was to use half-close shutdowns.

--
Sincerely

Hector Santos
http://www.santronics.com