One of the most important tasks of a network application is transferring data. This can be done differently depending on the kind of transport used, but what gets transferred is always the same: bytes over the wire. Transports help abstract how the data is transferred. All you need to know is that you have bytes to send and receive. Nothing more, nothing less.

clipboard.png
The ChannelConfig has the entire configuration settings stored for the channel and allows for updating them on the fly. Additionally, you can also modify the ChannelPipeline on the fly, which allows you to add/remove ChannelHandler instances whenever needed. This can be used to build highly flexible applications with Netty.

clipboard.png

如何注册Listener:
clipboard.png

Please note that Channel is thread-safe, which means it is safe to operate on it from different Threads. All it s methods are safe to use in a multi-thread enviroment. Because of this it s safe to store a reference to it in your application and use it once the need arises to write something to the remote peer, even when using many threads.

clipboard.png

NIO Transport的特性:
Because of the nature of this transport, it may come with a bit of latency when processing events, and so can have a lower throughput than the OIO transport. This is caused by the way the selector works, as it may take some time to be notified about state changes. I m not talking about seconds of delay, only milliseconds. This may not sound like much of a delay, but it can add up if you try to use your network application in a network where gigabit speed is offered.
One feature that offers only the NIO transport at the moment is called zero-file-copy. This feature allows you to quickly and efficiently transfer content from your file system. The feature provides a way to transfer the bytes from the file system to the network stack without copying the bytes from the kernel space to the user space.

OIO Transport的特性:
When using these classes, you usually have one thread that handles the acceptance of new sockets (server-side) and then creates a new thread for each accepted connection to serve the traffic over the socket. This is needed as every I/O operation on the socket may block at any time. If you share the same thread over more than one connection (socket), this could lead to a situation where blocking an operation could block all other sockets from doing their work.
Knowing that operations may block, you may start to wonder how Netty uses it while still providing the same way of building APIs. Here Netty makes use of the SO_TIMEOUT that you can set on a socket. This timeout specifies the maximum number of milliseconds to wait for an
I/O operation to complete. If the operation doesn t complete within the specified timeout, a SocketTimeoutException is thrown. Netty catches this SocketTimeoutException and moves on with its work. Then on the next EventLoop run, it tries again. Unfortunately, this is the only way to do this and still confirm the inner working of Netty. The problem with this approach is that firing the SocketTimeoutException isn t free, as it needs to fill the
StrackTrace, and so on.

Embedded Transport的特性:
The embedded transport allows you to interact with your different ChannelHandler implementation more easily. It s also easy to embed ChannelHandler instances in other ChannelHandlers and use them like a helper class.
This is often used in test cases to test a specific ChannelHandler implementation, but can also be used to re-use some ChannelHandler in your own ChannelHandler without event extend it. For this purpose, it comes with a concrete Channel implementation.

【P65】
4.4 When to use each type of transport

clipboard.png


bedew
278 声望3 粉丝