|Home >> All >> org >> szegedi|
|||org.szegedi.nbpipe.* (6)||||org.szegedi.nioserver.* (22)|
|||org.szegedi.nioserver.log.* (1)||||org.szegedi.nioserver.protocols.* (6)|
NioServer: The runtime class for non-blocking servers. Every NioServer manages a number of threads for accepting connections, reading, and writing. In the basic case, you will have a single thread for accepting connections and another single thread for processing read and write operations. However, if you are running the code on a multiprocessor machine, you can create more initial threads to improve CPU utilization. Also, when running on Windows, the server will spawn new threads when all current threads service 63 channels - the maximum number of channels a single thread (more precisely "the maximum number ...
NonblockingPipe: NonblockingPipe is a device for bridging between one-connection-per-thread code and the multiple-connections-per-thread (nio) code. The legacy code must be shielded from both the complexity of non-blocking I/O and from getting blocked on I/O. This is where a NonblockingPipe comes in. This pipe uses a ByteBufferPool to satisfy its memory needs, and does not work with an ordinary cyclic buffer that blocks write operations when full. This way, it is ideal for presenting InputStream and OutputStream interfaces for legacy code, while retaining full non-blocking I/O capacity.
NioHttpRequest: The interface that represents the parsed request as passed to an Adapter adapter for processing. It exposes the significant parsed request properties (method, URI, protocol, headers, and body), as well a stream for writing the response.
ByteBufferPool: A ByteBufferPool is a facility for dinamically managing a large number of byte buffers. It manages both direct memory and file-mapped buffers. In a normal usage pattern, an application will start by requesting a memory buffer, then after a demand for memory rises, it will switch to file-based buffers.
ServerSocketConfiguration: Specifies the characteristics of a server socket. A separate class is used by the NioServer clients for setting these characteristics, as the creation of the server socket object is hidden in the NioServer, and as such the server socket is not accessible directly by the client.
ProtocolHandlerFactory: An interface for factories of protocol handlers. A single protocol handler factory is associated with each serviced server socket. When a connection is accepted on the server socket, a new protocol handler is requested from the factory and associated with the connection.
Adapter: Adapter interface is a bridging between HttpProtocolHandler and a concrete facility that processes the request and generates a response (like a servlet container implementation, or an implementation that serves static files from the filesystem, and so on).
Service: The Service class represents each service that was registered with a NioServer. Basically, once you have registered a service with a server, you can do pretty little with it - this class allows you to retrieve the socket address, and to stop the service.
ProtocolHandler: Interface for objects that service read and write operations on a socket for a single connection.
TestGlobalByteBufferPool: The JUnit test suite for testing GlobalByteBufferPool functionality.
TestNonblockingPipe: The JUnit test suite for testing NonblockingPipe functionality.
TestNioServer: The JUnit test suite for testing NioServer functionality.
Log: Interface for NioServer logging adapters.
Log4JAdapter: A Log adapter for Apache Jakarta Log4J.