Add support for multiplexed channels in remoting::protocol::Session interface.

remoting/protocol/session.h

Index: remoting/protocol/session.h
diff --git a/remoting/protocol/session.h b/remoting/protocol/session.h
index 7041486be037313ab8a98875647bdfd9d009b30d..118ca0b9440f860c6135dfafcfd9ab06c2ec95a4 100644
--- a/remoting/protocol/session.h
+++ b/remoting/protocol/session.h
@@ -7,7 +7,6 @@
 
 #include <string>
 
-#include "remoting/protocol/channel_factory.h"
 #include "remoting/protocol/errors.h"
 #include "remoting/protocol/session_config.h"
 
@@ -18,12 +17,13 @@ class IPEndPoint;
 namespace remoting {
 namespace protocol {
 
+class ChannelFactory;
 struct TransportRoute;
 
 // Generic interface for Chromotocol connection used by both client and host.
 // Provides access to the connection channels, but doesn't depend on the
 // protocol used for each channel.
-class Session : public ChannelFactory {
+class Session {
  public:
   enum State {
     // Created, but not connecting yet.
@@ -98,6 +98,12 @@ class Session : public ChannelFactory {
   // ChromotocolServer::IncomingConnectionCallback.
   virtual void set_config(const SessionConfig& config) = 0;
 
+  // Return channel factories for the session. First one creates regular
+  // channels, while the second one creates multiplexed channels. All
+  // multiplexed channels work over a single regular channel.

[Wez, 2012/08/15 00:52:23]

The Session knows the configuration that is in-use, so I don't think there's any
need for callers to choose the ChannelFactory explicitly via the API; the
Session can implement ChannelFactory and call on to the
multiplexed/non-multiplexed factory based on the configuration data for the
named channel?

That would also mean you could replace the Session parameter to the various
channel readers & writers with ChannelFactory.

[Sergey Ulanov, 2012/08/15 01:35:42]

I don't think that would be the right approach.
 (1) channels may not always map to configuration. E.g. when we had RTP
reader/writer they were creating two separate channels - one for RTP and one for
RTCP.
 (2) Channel configuration is normally processed by the upper layer. E.g. if
event reader/writer supported datagram-based channel they would have to decide
to create a stream a datagram channel instead of a stream. We should try not to
spread that logic through several layers. The session layer just provides a way
to establish a session and connect channels. Yes, it also takes care of
negotiating session config, but that doesn't mean it has to change it's behavior
based on that configuration

[Wez, 2012/08/16 00:45:00]

Fair points. :(

+  virtual ChannelFactory* GetMainChannelFactory() = 0;

[Wez, 2012/08/15 00:52:23]

nit: GetSeparateChannelFactory()/GetIndependentChannelFactory()?

[Sergey Ulanov, 2012/08/15 01:35:42]

What do you think about GetBaseChannelFactory?

[Wez, 2012/08/16 00:45:00]

"Base" doesn't really convey "not-multiplexed", though. :-/

GetDedicatedChannelFactory(), perhaps? Or GetTransportChannelFactory()?

[Sergey Ulanov, 2012/08/16 00:59:49]

Ok, changed it to GetTransportChannelFactory()

+  virtual ChannelFactory* GetMultiplexedChannelFactory() = 0;
+
   // Closes connection. Callbacks are guaranteed not to be called
   // after this method returns. Must be called before the object is
   // destroyed, unless the state is set to FAILED or CLOSED.