another interesting thing - if we're going to let the protocol have things like extensions, why not have an extension that does multiplexing?
in this instance, let's say we have a connection where we stream large files (ping @6f7262), and we want to send multiple files at once over one connection (due to browser limitations or whatever) -- we could establish "channels", and have files be sent to different channels
if we do this on top of streaming (#84), i think we'll have an unbeatable balance of usability and speed
the extension would probably define the channel ID at the beginning of the protocol, like so:
before extension
+========+
+ data +
+========+
after extension
+-+-+-+-+========+
+ chn + data +
+-+-+-+-+========+
the big question will be how many bits to allocate for channel IDs, and if we should make them dynamic during extension negotiation or not
another interesting thing - if we're going to let the protocol have things like extensions, why not have an extension that does multiplexing?
in this instance, let's say we have a connection where we stream large files (ping @6f7262), and we want to send multiple files at once over one connection (due to browser limitations or whatever) -- we could establish "channels", and have files be sent to different channels
if we do this on top of streaming (#84), i think we'll have an unbeatable balance of usability and speed
the extension would probably define the channel ID at the beginning of the protocol, like so:
before extension
after extension
the big question will be how many bits to allocate for channel IDs, and if we should make them dynamic during extension negotiation or not