I think this is already taking place in the underlying layers. In my system, with Nagle's algorithm enabled (default MINA configuration) several MINA messages (albeit small ones, of course) get packed into a single Ethernet frame.
Zigor. On 21 Oct 2011, at 14:31, Alex Karasulu wrote: > On Fri, Oct 21, 2011 at 2:12 PM, Emmanuel Lecharny <elecha...@gmail.com>wrote: > >> On 10/21/11 12:56 PM, Zigor Salvador wrote: >> >>> Comments after using Wireshark to sniff on the packets being sent: >>> >>> On 20 Oct 2011, at 16:10, Emmanuel Lecharny wrote: >>> >>> Each message sent and received on ethernet will use 1500 bytes, even if >>>> you transmit only one byte of data. >>>> >>> This is not correct. >>> >>> Using MINA's "no delay" option and sending around 439 bytes of data the >>> Ethernet frame captured by Wireshark reports a total frame length of 505 >>> bytes. >>> >> >> That does not change the fact that Ethernet frames are 1500 bytes long... >> >> >>> (505 = 6 (MAC) + 6 (MAC) + 2 (Type) + 20 (IP header) + 32 (TCP header) + >>> 439 (data)) >>> >>> If I enable Nagle's algorithm, several messages get crammed into a single >>> ethernet frame (up to the aforementioned MTU value). >>> >> Nagle algorithm is not a good idea for small messages, as you will have a >> delay between each messages, the system waiting for some more bytes to fill >> the PDU as much as it can before sending it to the client. >> >> It's usefull when sending big data, though. >> >> > Wondering if MINA can get a little smarter. Just a brain dump here .... what > if you know according to the protocol that you're going to get a certain > train of responses. Maybe there's a way to buffer and dump to fill to MTU > capacity? > > -- > Best Regards, > -- Alex
