On Sat, Mar 29, 2003 at 04:04:11PM -0500, Zlatin Balevsky wrote: > Here is a tentative rollout of non-blocking polling for live > connections, assuming everything else (handshaking, authentication & > trailing field stuff) stays blocking. This should save 30-40% of > threads used. If authentication is also nio'd that percentage will rise > to above 50.
One thing at a time. But it looks like authentication would be the next item on the shopping list. The other side of all this is the client stuff often uses far too many threads - a 60 request splitfile should use ONE THREAD, not 60. > > 1. change all sockets used in fred to use channels. The changes to the > code are minimal (and already done in my local copy) but break > compatibility with jre's older than 1.4. > > 1.5 (optional) make the FNP and FCP interfaces non-blocking, thus saving > one thread. Again code changes are minimal. Side effect: We can listen to multiple interfaces on the FCP port. This could be useful for people who want to accept FCP from the LAN and localhost, but don't want the port to be visible externally. Could be implemented with another thread in the current design, of course. > > 2. After a connection is established on an interface and the > handshake/authentication is complete, change the socket to non-blocking > mode and pass it on to the object doing the select loop. > > 3. Implement the select loop. It will run in a single thread which is > recommended to have higher priority than the others. The object > representing the select loop will keep track of all open connections > (through connection handlers) and those who are receiving trailing > fields will be marked. The ConnectionHandler object will be augmented > with a flag whether its processing trailing field and with a buffer > holding received data. > > The basic operation of this select loop is the following: > > 3.1. block for any network input on the open connections for a > specified timeout (20-200ms?) Why the timeout? > 3.2. query those ConnectionHandlers that have been registered as > reading trailing fields, and if any of them have completed their reads > re-register their channels to the selector. Is this the reason for the timeout? Surely we could have them interrupt the select() when finished? > 3.3 Read the available data and put it in the buffers of the > appropriate ConnectionHandlers > 3.3.a) If the received data contains an "EndMessage", enter the > message parsing code and produce a messageObject. I'm assuming those > messageObjects are afterwards taken care of separate threads. > 3.3.b) If the received data contains an "Storable=", mark the > ConnectionHandler as busy, unregister it from the selector and change > the appropriate socket to blocking mode. After that enter the code > that deals with trailing fields in a separate thread. Wrong, discussed on IRC. Parse it into lines, all but the first and last in a message will contain an '='. Then make a FieldSet out of the middle, and if it contains DataLength, it has a trailing field. > 3.3.c) If neither of those is there, return and process the next > ConnectionHandler. > 3.4 Register to the selector any newly opened connections passed > from the interface. > > Other than implementing the loop, changes include checking whether a > complete message has been received before running the > ConnectionHandler.run() method. In that method the streams will have to > be backed either by a String or byte[]. No changes are required to the > code that deals with trailing fields because blocking streams work fine > with blocking sockets, except that right before dying the thread that You mean with nonblocking sockets? > reads the trailing fields must mark the ConnectionHandler as available > and wakeup() the selector. > > All in all, the amount of code changes is not as big as first expected. > If the authors of the current code don't mind being bothered by me > asking questions every so often, the transition can be done in 1-1.5 > months. Perhaps even less. Excellent. Ask anything you need, I at least will help, although I may not always be able to help directly with code. -- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://80-192-4-36.cable.ubr09.na.blueyonder.co.uk:8889/fl4hFW7uLxk/ ICTHUS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030329/334c7172/attachment.pgp>
