pid and fd & backlog for SYN packets

[seohyeon0322]

1. Can different process(pid) have the same file descriptor(fd)? Or file descriptor is an unique value?

2. I am confused about "backlog"in listen(). I thought the "backlog" limits the amount of SYN packet server can get. However, in TestAccept_Backlog2, backlog is 1 but expected_accept is 6. I thought expected_accept should be 1 as backlog is 1. Is my thought wrong?

[Pusnow]

Can different process(pid) have the same file descriptor(fd)? Or file descriptor is an unique value?

Each process has its own fd space, and different process can have the same fd number (number only, they point different connections).

I am confused about "backlog"in listen(). I thought the "backlog" limits the amount of SYN packet server can get. However, in TestAccept_Backlog2, backlog is 1 but expected_accept is 6. I thought expected_accept should be 1 as backlog is 1. Is my thought wrong?

It is a little bit tricky. In KENS, the backlog parameter limits the number of pre-established (currently handshaking) connections, not accepted connections.
Even if the listing peer does not call accept(), the connections can be established. The accept() only pops a connection from list of established connections.

KENSv3/app/kens/testhandshake.cpp

Lines 288 to 313 in a610761

	int server_pid =
	host1->addApplication<TestHandshake_Accept>(*host1, accept_env);
	connect_env["CONNECT_TIME"] = TimeUtil::printTime(
	TimeUtil::makeTime(10, TimeUtil::MSEC), TimeUtil::USEC);
	int client1_pid =
	host2->addApplication<TestHandshake_Connect>(*host2, connect_env);
	connect_env["CONNECT_TIME"] = TimeUtil::printTime(
	TimeUtil::makeTime(20, TimeUtil::MSEC), TimeUtil::USEC);
	int client2_pid =
	host2->addApplication<TestHandshake_Connect>(*host2, connect_env);
	connect_env["CONNECT_TIME"] = TimeUtil::printTime(
	TimeUtil::makeTime(30, TimeUtil::MSEC), TimeUtil::USEC);
	int client3_pid =
	host2->addApplication<TestHandshake_Connect>(*host2, connect_env);
	connect_env["CONNECT_TIME"] = TimeUtil::printTime(
	TimeUtil::makeTime(40, TimeUtil::MSEC), TimeUtil::USEC);
	int client4_pid =
	host2->addApplication<TestHandshake_Connect>(*host2, connect_env);
	connect_env["CONNECT_TIME"] = TimeUtil::printTime(
	TimeUtil::makeTime(50, TimeUtil::MSEC), TimeUtil::USEC);
	int client5_pid =
	host2->addApplication<TestHandshake_Connect>(*host2, connect_env);
	connect_env["CONNECT_TIME"] = TimeUtil::printTime(
	TimeUtil::makeTime(60, TimeUtil::MSEC), TimeUtil::USEC);
	int client6_pid =
	host2->addApplication<TestHandshake_Connect>(*host2, connect_env);

In Backlog2, the connect() intervals are about 10 microseconds, which is enough time for handshaking. Thus all connections can be accepted.

If you are interested more, read below.

The effect of the backlog parameter is implementation-specific, and there are differences among implementations.
In modern Linux, the backlog parameter means the queue length for completely established sockets waiting to be accepted.
Linux before v2.2, the backlog parameter means the number of incomplete connection requests (same as KENS).

See NOTES in listen(2):

KENSv3/Documentation/man/listen.2.txt

Lines 60 to 64 in 22b8748

	The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the
	queue length for completely established sockets waiting to be accepted, instead of the number of in‐
	complete connection requests. The maximum length of the queue for incomplete sockets can be set us‐
	ing /proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are enabled there is no logical maximum
	length and this setting is ignored. See tcp(7) for more information.

FreeBSD also has a different meaning (https://www.freebsd.org/cgi/man.cgi?query=listen&sektion=2&format=html).