Kamran Karimi wrote:
> 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).
Do you mean that you bind() the client socket to 6543, or the server
socket?
If you bind both ends, so that every connection has exactly the same
parameters (source IP, source port, destination IP, destination port),
then every connection will have to wait for the previous one to leave
the TIME_WAIT state.
Given that you are getting 250 connections per second, this seems
unlikely.
> 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).
Yes, because eventually the connection will leave the TIME_WAIT state
and you will be able to create a new connection with the same
parameters.
> And the same program, on the same network, but between slower
> machines does not fail in such a way.
Yes, because by the time that you have used every possible source
port, the first connection will have left the TIME_WAIT state, so you
can reuse the port.
> It also goes away in faster machines if I insert
> delays between network connections.
Yes, because by the time that you have used every possible source
port, the first connection will have left the TIME_WAIT state, so you
can reuse the port.
> 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.
Note that making large numbers of TCP connections where 3 of the 4
parameters (source IP, destination IP, destination port) remain
constant doesn't make for a particularly good benchmark.
All that it really does is to show you one of the limitations which
arises from TCP using 16-bit port numbers. I.e. that you can't create
a connection where all 4 parameters match some previous connection
until you can be sure that there aren't any stray packets from the
previous connection still floating around on the 'net.
> 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).
Actually, a specific number of operations may provide a better test.
If you run until the connect() fails, then the TIME_WAIT issue doesn't
come into it.
--
Glynn Clements <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
