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. TCPConduits 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