Update SSLServerSocket to provide the net::StreamSocket interface.

remoting/protocol/jingle_session.cc

Index: remoting/protocol/jingle_session.cc
diff --git a/remoting/protocol/jingle_session.cc b/remoting/protocol/jingle_session.cc
index 90aaf0813a72c38ea4a3b8b2e526ddc47c99f246..91565a0eb630aa99a6735d1f4557db66ef916d9c 100644
--- a/remoting/protocol/jingle_session.cc
+++ b/remoting/protocol/jingle_session.cc
@@ -400,11 +400,11 @@ bool JingleSession::EstablishSSLConnection(
   } else {
     // Create server SSL socket.
     net::SSLConfig ssl_config;
-    net::SSLServerSocket* socket = net::CreateSSLServerSocket(
+    net::StreamSocket* socket = net::CreateSSLServerSocket(

[wtc, 2011/06/02 23:12:58]

Change this back to SSLServerSocket.

[Wez, 2011/06/03 17:47:07]

Done.

         pseudotcp, server_cert_, key_.get(), ssl_config);
     ssl_socket->reset(new SocketWrapper(socket));
 
-    int ret = socket->Accept(&ssl_connect_callback_);
+    int ret = socket->Connect(&ssl_connect_callback_);

[willchan no longer on Chromium, 2011/06/03 10:23:44]

I don't believe we should make this change. Use Accept() instead. We may want to
consider removing Connect() from the StreamSocket interface and adding a new
interface that inherits from StreamSocket that provides the Connect() method. I
need to think further. But I'm pretty sure there's no need to call Connect()
here. Calling Accept() or whatever you want to call it other than Connect()
seems fine to me.

[Wez, 2011/06/03 17:47:07]

I chose to re-use Connect() for three reasons:

1.  There is no semantic difference between SSLClientSocket::Connect() and what
I've called SSLServerSocket::Connect(); both cause the SSL handshake to be
performed over the already-connected underlying StreamSocket(*).  Giving the two
the same name allows more common code between the client and server sides of an
application that uses the two.

2.  Conceptually the Connect() call makes a StreamSocket "connected" - in the
case of SSL that means performing the handshake, which is exactly what this call
does.

3.  accept() is an operation on a listening socket in the BSD sockets world, and
that is the model that net::Socket and net::ServerSocket seem to follow.  The
only reason I can see for the call previously having been called Accept() is
that OpenSSL uses that terminology in places.

(*)  That said, the semantics of SSLClientSocket::Connect() don't quite match
those described for StreamSocket::Connect(), so the equivalence may go away if
that gets fixed.

The SSLServerSocket class name is confusing, since it implies that this is a
net::ServerSocket.  Similarly, the Connect() semantics of both SSLClientSocket
and SSLServerSocket aren't what a net::StreamSocket caller would expect;
splitting the current StreamSocket::Connect() into client-side Connect() and
client/server-common Handshake() calls could address that.

I'm more than happy to help improve the net::Socket class hierarchy and
interfaces to be more consistent, but I don't think this CL is the place to do
it. :)

[wtc, 2011/06/03 18:03:40]

I agree with willchan's comment and wez's comment here.
The difficulty here is what to call the "connection setup"
method of a server-side layered socket.  Perhaps reserving
Connect() and Accept() for transport sockets and adding a
Handshake() method, which takes no destination address
argument and operates in either client or server mode, for
layered sockets is a good solution.

     if (ret == net::ERR_IO_PENDING) {
       return true;
     } else if (ret != net::OK) {