* Ideas/todo:

 - Todo right now: 
   + callbacks use VUtil listener template

 - Prediction for LLP still isn't ideal -- it is a great improvement
 over the naive way of doing it, but it still doesn't deliver as well
 as I'd like.  Should perhaps develop a better way to analyze the
 algorithm than just twiddling with it...

 - Would be nice to have a "reset" feature to abort downloads in
 std/bulk. Meaning, if you hand VIP a big hunk of data you want to
 send, you can cancel sending it halfway through.  Since VIP is
 just going to be pushing the data up to VOS, VOS needs to know that
 the message transfer is done so it can reset its own buffering and
 that the next chunk of data on that channel is actually a new
 message.  Will need to stick some more info in the std/bulk header.
 Maybe a TCP-style "options" field?

 - Think about how to implement SACK for std/bulk transfer (use options
 field?)

 - Determine if it's possible to do streaming from subclassing
 StandardProtocol.

 - Implement unreliable "protocol"


Pkt format
  [1/ control]

iff SYN:
  [1/ offsets]
  [(0..16)*2/ proto block offsets]

Low Latency: (14 bytes + 6 bytes/msg for header)
  [1/ proto]
  [4/ last recieved sequence number]
  [4/ starting sequence number]
  [4/ ending sequence number]
  [1/ number of msgs]
  {#/ [1/ seq offset][4/ msg id][1/ msg size][#/ data]}

Standard/Bulk: (5..69 bytes + 6 bytes/stream for header)
  [1/ proto]
  [2/ ack flags]
  [(0..16)*4/ acks for each channel there is unacked data]
  [2/ active channel flags]
  {#/ [4/ starting seq num][2/ size][#/ data]}

Streaming: (5..197 bytes + 6 bytes/stream for header)
  [1/ proto]
  [2/ ack flags]
  [(0..16)*12/ acks for channels with unacked data, current buffer usage, max buffer size]
  [2/ active channel flags]
  {#/ [4/ ending seq num][2/ size][#/ data]}

Unreliable: (3 bytes header)
  [1/ proto]
  [2/ block size]
  [#/ data]