On 2011-08-22 21:17:07 -0400, Hector Santos wrote:
Sounds like a bug or poor windows socket implementation, not yours, the
other guy. :) #1 rule of thumb in Synchronization 101 is to not depend
on time.
Too bad the designers of TCP didn't know this ...
Inevitably it will bite you, maybe this year or even never, but
somehow it will rear its head. :) So if lowering TIME_WAIT was one
solution, it generally means there is some kind of sync design problem
and it might be a matter of issue a one time poke (Sleep(0)) to give
other threads time, but immediately coming back. Sometimes it can make
all the difference. :)
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.
hp
--
_ | Peter J. Holzer | Web 2.0 könnte man also auch übersetzen als
|_|_) | Sysadmin WSR | "Netz der kleinen Geister".
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Oliver Cromm in desd
signature.asc
Description: Digital signature