Implement ChannelMultiplexer.

remoting/proto/mux.proto

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+//
+// Protocol for the mux channel that multiplexes multiple channels.
+
+syntax = "proto2";
+
+option optimize_for = LITE_RUNTIME;
+
+package remoting.protocol;
+
+message MuxPacket {

[Wez, 2012/08/06 23:14:07]

nit: MultiplexPacket

[Sergey Ulanov, 2012/08/07 20:12:22]

Done.

+  // Channel ID. Each peer choses this value when it sends first packet to
+  // the other peer. It unique identified channel this packet belongs to.
+  // Channel ID is direction-specific, i.e. each channel has two IDs
+  // assigned to it: one for receiving and one for sending. E.g. if peer A
+  // assigns ID 1 to a channel and peer B assigns ID 3 to the same channel
+  // then packets sent for that channel from A to B will have id=1, while
+  // packets sent from B to A will have id=3. Both peers need to keep track
+  // of both values.

[Wez, 2012/08/06 23:14:07]

nit: I don't think you need the example here; it's fine just to say that every
MuxPacket includes the channel identifier, and that at least the first MuxPacket
for a given channel specifies the name, so that the receiver can build a mapping
of channel Ids.

[Wez, 2012/08/06 23:14:07]

nit: The downside to this approach is that receiver code can't switch() on the
channel ID in received MuxPackets, since the IDs are allocated by the sender,
not the receiver.

[Sergey Ulanov, 2012/08/07 20:12:22]

Done.

[Sergey Ulanov, 2012/08/07 20:12:22]

It would make protocol more complicated if the IDs were assigned by the
receiver. Don't think it's worth worrying about.
We can assign fixed ID to each channel, but identifying channels by ID is not a
good approach.

+  optional int32 channel_id = 1;
+
+  // Channel name. The name is used to identify channels before channel ID
+  // is assigned in the first message. This value must be included only
+  // in the first packet for a given channel. All other packets must be
+  // identified using channel ID.
+  optional string channel_name = 2;
+
+  optional bytes data = 3;

[Wez, 2012/08/06 23:14:07]

What is the overhead to copying the actual message data into the MuxPacket
rather than having MuxPacket be a header, and indicating how many bytes of
message data follow?

[Sergey Ulanov, 2012/08/07 20:12:22]

I don't think it's big enough to worry about since we don't intent to use this
channel to send very big messages. In any case, if it becomes a problem we can
hack protobuf message serialization/deserialization code such that it wouldn't
require copying that memory. And that would require changing on-wire format of
the messages. 

[Sergey Ulanov, 2012/08/07 20:13:58]

I meant it would _not_ require changing on-wire format of the message.

+}