Announcement Announcement Module
No announcement yet.
TCP Response (reportedly) on incorrect session Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • TCP Response (reportedly) on incorrect session

    We have a client making x number (configurable) connections to our tcp listener. The client application has reported that they are seeing a response for a request arrive on a different session (connection) than the one it originally was issued on. We have verified on our side that the ip_connection_id is the same for the incoming request and the response. We've also verified the echo is the same. What we can't verify is that after processing the request, the response is sent back on the same connection from which it originated (unless the ip_connection_id is unique for each connection created to our listening server.)

    1. Does SI create a new ip_connection_id for each connection to a tcp/ip listener? I'm currently writing a test case to see if this is true. But if anyone knows off hand, your validation would be great.
    2. Would SI naturally send responses to requests on different ip_connection_ids? Or would this only happen in some error scenario?
    3. How can I demonstrate, from the server side, that my application is sending responses on the originating session?

  • #2
    1. Each connection gets a new, unique, ID

    this.connectionId = this.hostName + ":" + port + ":" + UUID.randomUUID().toString();
    Note; prior to 2.1.0, 2.0.6, we used the hashCode, not a UUID, so you could get duplicates, but not with concurrently open sockets.

    2. It should never happen; the connections are mapped using the id...

    Object connectionId = message.getHeaders().get(IpHeaders.CONNECTION_ID);
    TcpConnection connection = null;
    if (connectionId != null) {
    	connection = connections.get(connectionId);
    if (connection != null) {
    	try {
    3. Probably the easiest way to show this is to use wireshark or similar to trace the network traffic. Then for each connection, use its 'Follow TCP Stream' feature to build a trace of all interations on that connection. The capture could get quite large so you might want to filter it so it just captures traffic to the client ip address.


    • #3
      Thanks, Gary!

      This is exactly what I thought was happening. Thanks for confirming