Matthew Toseland wrote: > On Thu, Oct 31, 2002 at 07:21:11AM +0200, Tuomas Lukinmaa wrote:
>>It might be better to use IP TTL value for seperating local and > > I very much doubt that java gives us access to this; if necessary I will > implement a user configurable list of IP address/netmask/bandwidth > limiter settings. You're correct. After little of Googling and frustration, it seems the only way to do it is to either use JNI to set the TTL on socket, write own SocketImpl or extend PlainSocketImpl to add TTL handling. It's strange that setting TTL is not supported in Java though it isn't priviledged function on most OS'es.. >>non-local connections. Some networks use mixed private and normal >>addresses together on WAN scale. Another good thing would be setting >>larger send/receive buffers (SO_SNDBUF/SO_RCVBUF) to allow larger >>transfer windows to be used. > > Hmm. We have disabled nagle's algorithm, so it will not buffer anything > at the OS level, right? What would stop it from transferring what we > feed it in packets the size that we feed it, apart from the common limit > of ~ 2kb, and the hard limit of 64kb for ip4? Nagle only works on sending small packets (less than network MTU to the destination host) by joining them in one larger lump. If the application sends larger packets than the MTU, the Nagle is bypassed anyway. Now where the send buffers comes in play is when the application feeds the OS large amounts of data to send: if a send overflows the OS buffer, the OS stalls next send until enough packets have been sent to the network to remove the overflow. If it happens that a send overflows the buffer and is larger than the buffer size, the next send might stall until the entire buffer is first cleared and the last send is processed. Same applies on receiving: if the receive buffer overflows, the OS stops ACKing packets (thus prevents application caused congestion) until the application empties the buffer. It doesn't matter if you're using blocking or non-blocking sockets, with non-blocking sockets the application will know what happened to the socket call (send or receive). Of course if you're soft-limiting to ~2KB packets, the default buffer sizes should be enough to prevent overflows if there is substantial delays between sends. With ~64KB packets you'll overflow the default buffers for certain on send and receive ends. References (mostly win32 ones but should apply to other OS'es with slight variations): http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q214397&; http://groups.google.com/groups?selm=avkn9.38%242i3.7680130%40newssvr30.news.prodigy.com http://groups.google.com/groups?selm=OrewU4ylBHA.604%40tkmsftngp02 _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
