Virtual byte channels need flow control

[Rob Eden]

Currently, the sending side for a channel will send at max speed with no back pressure. If the receiving side can't keep up, it will run out of memory.

[Rob Eden]

To deal with flow a simple "window" mechanism will be added (along with an MTU) to channels.

Message changes:

• ChannelInit

  • Add "rx window" - a value in bytes which is the most data which the "server" side could send to the "client" side without an ack.

• ChannelInitResponse

  • Add "rx window" - same as above, but for data sent from the "client" to the "server"

• ChannelData

  • Add "packet ID" - short (or maybe int) identifier of the packet from the sender's perspective. Counter is tracked by the sender and receiver doesn't care about ordering. Sender will only use them to ack up to a particular point.

• New message type: ChannelDataAck

  • Channel ID
  • Message ack - ID of the message up to which we're acking (from ChannelData's message ID). All data sent before the indicated message is also ack'ed.
  • (Optional) new rx window size

Other possible addition: an MTU in the session init which specifies the max length that can be sent in any data array. (Would also like to include invokes & returns, which would require fragmenting. So, this is probably best as another issue.

[Rob Eden]

Sending side will keep track of amount of data sent but not acked. When a ChannelData message send is requested, it will block if the outstanding data amount is at or over the current window size.

[Rob Eden]

Reference links on window algorithms:

• https://tools.ietf.org/html/rfc813

[Rob Eden]

Virtual channel flow control, protocol version 3 (initial work)

Virtual byte channels now implement flow control to throttle the rate of incoming messages to prevent OOMs due to a never-ending receive message queue. Flow control is disabled when connecting to older peers (not implementing protocol version 3).

As indicated above, the protocol version has been incremented to version 3. The changes for proto version 3 are not complete in this merge (see #16), but they have begun. By default connections to hosts with proto version <3 are no longer allowed. To enable connections to older peers the system property intrepid.min_supported_protocol can be used. For example: -Dintrepid.min_supported_protocol=2.

In addition to VBC flow control, proto 3 aims to optimize and clean up message formats. As a first step, this merge also removes the per-message-type version field in all messages but SessionInit and SessionInitResponse.

Finally, MINA buffer allocation tunables have been added: * intrepid.mina.encoder.allocate_cached - When present, the caching allocator will be used rather than the simple allocator. * intrepid.mina.encoder.allocate_size - Initial size (in bytes) to use for message encode buffers. The initial size used to be 256k but has been reduced to 2k. * intrepid.mina.encoder.allocate_direct - When present, buffers will allocate as direct buffers.

Fixes: #15 Relates to: #16

→ <<cset 8b895e4662ad>>