All the sockets use the same port number (6543), which is beyond the
range of ephemeral ports (1024-4999 on my 2.2.11 kernel).
Test machines are two PII @400Mhz. The network runs at 10Mb/s. The
problem seems to be resolved all by itself if I just wait a short time
(i.e. I can use FTP again without a need for reboot or anything). And the
same program, on the same network, but between slower machines does not
fail in such a way. It also goes away in faster machines if I insert
delays between network connections.
The benchmark program is part of the DIPC (http://wallybox.cei.net/dipc)
package. I want to measure the speed of some network operations with it.
In the current implementation, I invoke the network operations in a loop
for a specified amount of time. This seems better than executing the
operations a certain number of times, because getting a suitable number for
the iteration is hard (if it is too large, the test takes too long on
slow machines and networks; if it is too low then faster machines and
networks won't measure it reliably).
Is there any way we can know what the kernel limit is?
-Kamran
> AFAICT, it's somewhere between a kernel limitation and a TCP
> limitation.
>
> What I presume is happening is that whichever port number is chosen
> for the client end will produce a socket which conflicts with one
> which is in the TIME_WAIT state.
>
> > Can I avoid this problem without having to limit the number of
> > connections in my benchmark program?
>
> On 2.2.*, you can increase the number of ephemeral ports available by
> writing to /proc/sys/net/ipv4/ip_local_port range.
>
> However, this will only make the problem harder to trigger.
> Ultimately, if you make connections fast enough you will run into the
> fact that TCP only uses 16-bit port numbers.
>
> --
> Glynn Clements <[EMAIL PROTECTED]>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
