Add TCP socket mojo interfaces

mojo/services/public/interfaces/network/tcp_socket.mojom

+// Copyright 2014 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.
+
+import "mojo/services/public/interfaces/network/net_address.mojom"
+import "mojo/services/public/interfaces/network/network_error.mojom"
+
+module mojo {
+
+struct TCPSocketInfo {
+  NetAddress local_address;
+  NetAddress remote_address;
+};
+
+// Represents a TCP socket. A socket can represent either a connection to a
+// remote host, or a local server socket waiting for incoming connections.
+//
+// For client connections:
+//  - Connect(), providing a pair of streams to use for data transfer.
+//  - Read and write from the streams as desired.
+//  - Close().
+//
+// For server connections:
+//  - Bind() to allocate a port.
+//  - Listen() to start listening for incoming connections.
+//  - For as long as you want to accept incoming connections:
+//    - Accept() to wait for and initiate a connection once one is available.
+//  - Close().
+interface TCPSocket {
+  // Binds this connection to a local port. The TCPSocket must not be bound,
+  // listening, or connected.
+  //
+  // This function is required to initialize a server socket for using Listen(),
+  // but is optional when using Connect() to initiate a client connection.
+  Bind(NetAddress addr) => (NetworkError result, TCPSocketInfo? info);

[yzshen1, 2014/09/30 20:26:13]

Because there is no remote address at this point yet, maybe it makes sense to
simply remove TCPSocketInfo, and use local_addr and remote_addr as needed?

[brettw, 2014/09/30 20:32:13]

I changed this case to be a NetAddr? but kept the struct for the other cases.
Having the struct is much easier for the two addresses since it is easy to get
the arguments confused.

+
+  // Starts listening on this socket for incoming connection requests. The
+  // socket must be bound and not connected.
+  //
+  // The backlog is a hint indicating the number of incoming connections that
+  // can be queued up at one time waiting for Accept(). This queuing will
+  // happen when connections are incoming faster than Accept() can be called.
+  Listen(int32 backlog) => (NetworkError result);
+
+  // Accepts a connection. The socket must be listening.
+  //
+  // This function is called to accept an incoming connection.  The caller
+  // provides the streams that will be used to send and receive data on the
+  // connection.
+  //
+  // On success, the callback will be provided with the new socket that
+  // represents the connection. It will already be in a connected state and the
+  // data streams will be ready to use.
+  Accept(handle<data_pipe_consumer> send_stream,
+         handle<data_pipe_producer> receive_stream) =>
+      (NetworkError result, TCPSocket? socket, TCPSocketInfo? info);
+
+  // Connects the socket to the given address. The socket must not be listening
+  // or previously connected. Binding the socket beforehand is optional.
+  Connect(NetAddress addr,
+          handle<data_pipe_consumer> send_stream,
+          handle<data_pipe_producer> receive_stream) =>
+      (NetworkError result, TCPSocketInfo? info);
+
+  // Closes the connection or stops listening for connections, depending on
+  // whether this socket is in server or client mode. If Close() is not called,
+  // the connection will be implicitly closes when the TCPSocket has been
+  // deleted.
+  Close();
+
+  // Controls whether small writes are coalesced to make TCP segments, and
+  // instead delivers data immediately. The default value is true (coalescing
+  // enabled).
+  SetCoaleseWrites(bool coalesce);

[viettrungluu, 2014/09/30 20:34:41]

Having a setter but no getter seems bad.

Also, not being able to set multiple options (if/when we add more) at once seems
bad.

Maybe this should be:

SetOptions(TCPSocketOptions options) => (NetworkError result);

where TCPSocketOptions looks like:

struct TCPSocketOptions {
  bool? coalesce_writes;
};

(There should also be a |GetOptions() => (TCPSocketOptions? options);| or
something like that.)

[brettw, 2014/09/30 20:44:15]

My plan was to use the mojo versioning to add functions for different options.
There are three options in Pepper and the other ones control buffering, so I
wasn't particularly concerned that we'd add more.

If we do add more, an enum corresponding to the BSD socket API would be better,
since the struct seems like it will make it harder to add options in a
backwards-compatible way.

I feel like this API will be used more often at a lower-level than the Pepper
one, so maybe some of the conjestion control options would make sense?

+};
+
+}