Index: remoting/proto/mux.proto |
diff --git a/remoting/proto/mux.proto b/remoting/proto/mux.proto |
new file mode 100644 |
index 0000000000000000000000000000000000000000..099611981b6f0178ddcd186208bb07e37daeff51 |
--- /dev/null |
+++ b/remoting/proto/mux.proto |
@@ -0,0 +1,31 @@ |
+// 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
Wez
2012/08/06 23:14:07
nit: The downside to this approach is that receive
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
|
+ 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
Sergey Ulanov
2012/08/07 20:12:22
I don't think it's big enough to worry about since
Sergey Ulanov
2012/08/07 20:13:58
I meant it would _not_ require changing on-wire fo
|
+} |