On Oct 24, 10:56*pm, asit wrote:

> I designed a port scanner with default timeout. So it takes a lot of
> time to scan an ip in it's *own subnet.
>
> Can anyone tell me what should be the optimal timeout value ???

You're solving the wrong problem. The problem is not the timeout
value, it's that you're waiting for something to timeout when you
should be working on other things at the same time.

DS

asit writes:
> I designed a port scanner with default timeout. So it takes a lot of
> time to scan an ip in it's own subnet.
>
> Can anyone tell me what should be the optimal timeout value ???

As already written: None at all. Send SYNs. Collect SYN-ACKs. If you
want to be nice, send RSTs as response to a SYN-ACK to inform the
server you just molested that you really only intended to ring the
bell to determine if someone would open.

NB: This means the process will need the necessary privileges to be
allowed to send self-composed IP datagrams containing TCP segments.

On Oct 25, 5:56*am, asit wrote:
> I designed a port scanner with default timeout. So it takes a lot of
> time to scan an ip in it's *own subnet.
>
> Can anyone tell me what should be the optimal timeout value ???

I presume the optimal timeout value should be such, that scanning does
not take a lot of time. Now, how much time can be considered "a lot"
depends on how the scanner is supposed to be used.

If you scan ports one at a time, the total timeout for scanning one
port should be desired-total-scan-time / number-of-ports-to-scan.

If you scan several ports at a time (using non-blocking IO, for
example), the total timeout for scanning one port should be desired-
total-scan-time / (number-of-ports-to-scan / number-of-ports-scanned-
simultaneously).

I say "total timeout for scanning one port" because to scan a port you
may need to send-receive several datagrams. Therefore, the timeout for
every read/recv/recv_msg() call should be total-timeout-for-scanning-
one-port / number-of-recv-calls-required-to-scan-one-port.

Is it what you asked for?

--
Max