Hey
This was just posted to the RMI-USERS list. Since some of you use WinNT
Workstation, it might be interesting to know about how server connection
backlogs are handled. This is especially important if you do the "spawn
x threads and have them hit the server" test. The below must then be
accounted for, i.e. put in a delay between each thread spawn so that
socket connections don't overflow the OS's backlog.
-------
Quoting ??? <[EMAIL PROTECTED]>:
> Resizeing the backlog queue size is the necessary condition
> if you want your application server to run in the heavy load.
> SYN Flooding attack is one of the common DOS(denial of service) attack.
> It also use the flooding the backlog queue.
>
> I am not sure the default value of backlog queue size for NT or UNIX systems.
> But you must check the value and twick it for your rubust service.
>
> I am not sure that the creating the ServerSocket(int port, int backlog)
> can change the backlog queue size. I have not test it.
> I guess each OS can have different results.
>
> As I know, the backlog queue size is the system configuration value, not user
> process configuration value. In my experience, old UNIX system did not
> suppported user level backlog queue size configuration.
>
> How about current OSs ???
> Does anybody has any idea about this.
In normal cases[1], java.net.ServerSocket simply passes the backlog
value it is
given to the listen system call of the underlying OS. The OS in turn
may
truncate this value silently if it exceeds an (implementation-dependant)
maximum threshold. For instance, on NT 4.0 Workstation, the maximum
backlog
value is 5[2], meaning that even if you write a native Windows program
which
specifies a higher backlog value in its call to listen(), the socket
will still
only queue a maximum of 5 pending connections. On NT 4.0 Server, the
limit is
200[2]. On Linux, the maximum backlog is 128 by default and tunable by
recompiling the kernel with a different SO_MAXCONN value[3] (I believe
the same
is true for *BSD). On recent versions of Solaris, the backlog limit is
controlled by the tcp_conn_req_max_q parameter, which is also set to 128
by
default[4].
At the RMI level, providing a custom socket factory which uses a larger
backlog
value may help in some cases, but may also have no effect in others due
to
these silently enforced system-imposed backlog limits.
-Mike
[1] If the given backlog value is 0 or negative, a default backlog value
(currently 50) is used instead.
[2] http://support.microsoft.com/support/kb/articles/Q127/1/44.asp
[3] http://lxr.linux.no/source/include/linux/socket.h#L190
[4] http://docs.sun.com:80/ab2/coll.709.2/SOLTUNEPARAMREF/
--
Rickard Öberg
Email: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
