> From: David kerber [mailto:[email protected]]
> Just over 1000 total, 810 to the port that this application is using.
"Should" be fine on Windows.
> The vast majority are showing a status of TIME_WAIT, a dozen or so in
> ESTABLISHED and one (I think) in FIN_WAIT_1.
Sounds fair enough. The ESTABLISHED ones are active both ways and able to
transfer data; the one in FIN_WAIT_1 has been closed at one end but the other
end's still open; and the ones in TIME_WAIT are closed but tombstoned so the
TCP stack knows to throw away any data that arrives for them. None of those
are a surprise.
> That's our corporate connection, so it's shared across all
> users. I can
> easily run it up to 100% it by doing a large d/l from
> somewhere (I need
> to plan my patch Tuesday updates to avoid trouble), so my router and
> firewall have no trouble handling the full bandwidth.
Ah, OK.
> However, those
> are low numbers of high-throughput connections. This app
> produces large
> numbers of connections, each with small amounts of data, so
> it may scale differently.
It may, but I'd be a little surprised - IP is IP, and you have enough
concurrency that latency shouldn't be a problem.
That said, if a client has multiple data items to send in rapid succession,
does it accumulate those and batch them, or does it send each one as a
different request? Or does the situation never arise?
- Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
