Contains TCP/IP communications conduit

The tcp/ip conduit is designed to be used in one way:

1) The conduit is used by the GemFire {@link org.apache.geode.distributed.internal.Distribution} when true multicast messaging is not needed and disable-tcp is not set to true, which is the default setting. When used in this way, the conduit manages the serialization and transmission of {@link org.apache.geode.distributed.internal.DistributionMessage} objects from one system to another. The {@link org.apache.geode.distributed.internal.Distribution} routes outgoing messages to TCPConduit and handles receipt of messages received by TCPConduit {@link org.apache.geode.internal.tcp.Connection "Connections"}.

Messaging uses DataSerializer serialization to send messages (and receive replies).

The GemFire Cache implementation initializes a `TCPConduit` when the cache is initialized. `TCPConduit`s created by the cache use a wildcard bind to select a server port unless the property tcpServerPort is set. If you're building a service using `TCPConduit` you may want to use a fixed port so that if your service exits it can restart on the same port.

The design of the conduit is fairly simple. `TCPConduit` owns the {@link java.net.ServerSocket} that accepts connections from other conduits. {@link org.apache.geode.internal.tcp.Connection "Connections"} are kept in a {@link org.apache.geode.internal.tcp.ConnectionTable ConnectionTable}.

The use of NIO can be turned off with the property `p2p.oldIO=true`. This will force the use of sockets instead of socket channels. Each `Connection` always creates a reader thread for pulling information out of its socket.

NIO and oldIO communications are interoperable

`TCPConduit` is used to send and receive messages using endpoint `Stubs` holding target host/port information. The conduit uses this information to select the correct `Connection`, or to create a new one if necessary. When sending a message, the conduit passes the message to the `Connection` and waits until transmission is complete before returning. Messages and responses received by a `Connection` are passed to the `TCPConduit` which routes them to their final destination.

When a message is received from another conduit it is deserialized and examined. If it is a `DistributionMessage`, the message is delegated to the `DirectChannel` held by the `MembershipManager`.

TCPConduit -----> ConnectionTable | | | v v v Connections

When a Connection is formed between two conduits, the client side (the one initiating the connection) transmits its `TCPConduit's` `ServerSocket` port. This port is used to identify the connection instead of the regular socket port. This allows all `Connection` objects to be identified by their associated server ports and makes connection management much simpler.

Other property settings that affect the conduit:

      p2p.tcpBufferSize - the size of operating system buffers on the tcp socket.
          outgoing messages.  The default is 32768.

      p2p.readerBufferSize - the size of the buffer used by reader threads
          to buffer incoming data.  The default is 32768.

      p2p.VERBOSE - turn on verbose logging at finer and finest log settings

      p2p.defaultLogLevel - level of logging to use if there is no distribution
          manager or gemfire log writer.  The value is "info", "config", "fine"
          etc

      p2p.DEBUG - turn on VERBOSE and defaultLogLevel of "finest"

      p2p.oldIO - turn off the use of java.nio for I/O operations.  If there is
          a custom socket implementation being used in the VM that doesn't support
          NIO you might want to use this property.

      p2p.useSSL - causes the conduit to use the javax.ssl JSSE factory to create
          its server socket.  This also sets p2p.oldIO=true since SSL sockets
          don't currently seem to support NIO.  TCPConduit has the method
          getSSLSession(serverId) that can be used to retrieve the SSL
          session for a given connection.  The serverId argument is a stub.

      p2p.idleConnectionTimeout - how long a thread owned connection can be idle
          before it will be closed.

Some of these properties are instance-specific and can be set when you create the conduit by passing a {@link java.util.Properties} object with the settings. When you use this form of the `TCPConduit` constructor, the conduit will not search for these settings in system properties:

          p2p.tcpBufferSize
          p2p.idleConnectionTimeout