Announcement Announcement Module
Collapse
No announcement yet.
TCP Connections Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • TCP Connections

    Hi,

    I have several TCP connections to a group of applications that need to talk to each other. I can send and recieve on one socket, but when my server has another, it stops working. What parameters need to be set for Spring to handle multiple server connections?

    <int-ip:tcp-connection-factory id="ServerIn"
    type="server"
    port="8060"
    so-timeout="5000"
    serializer="connectionSerializeDeserialize"
    deserializer="connectionSerializeDeserialize"/>

    <int-ip:tcp-connection-factory id="ServerOut"
    type="server"
    port="8061"
    so-timeout="5000"
    serializer="connectionSerializeDeserialize"
    deserializer="connectionSerializeDeserialize"/>

    <bean id="connectionSerializeDeserialize" class="org.springframework.integration.ip.tcp.seri alizer.ByteArrayStxEtxSerializer"/>

    <int-ip:tcp-inbound-channel-adapter id="inbound"
    connection-factory="ServerIn"
    error-channel="errorChannel" channel="out"
    auto-startup="true" />

    <int-ip:tcp-outbound-channel-adapter channel="out"
    connection-factory="ServerOut" id="outbound" order="1"
    auto-startup="true" />

  • #2
    Please use [ code ] ... [ /code ] tags (no spaces inside brackets) when posting code or configuration.

    If that is your entire configuration, I don't see how it can ever work, even with one connection.

    You have 2 server connection connection factories. It looks like you want to have a client connect to 2 sockets, send a request on one and receive a reply on the other. You simply have your inbound adapter wired up directly to your outbound adapter. That is a very unusual configuration.

    It won't work because the outbound adapter needs information to decide which socket to send the data on; since the inbound message didn't come from that connection factory, there is nothing in the message we can use to do that correlation.

    Perhaps if you can describe your use case I can make some suggestions on how to configure things.

    Comment


    • #3
      Thanks for the reply.

      I have a client connection factory in another java application. It can send a string message into the server but it doesn't come back.

      I am making a bus example and this represents the server. The clients at either end will be client sockets connected to the respective port.

      Thanks
      Ed

      Comment


      • #4
        Like I said, there is no out-of-the-box support for receiving a message on one socket and sending a reply on some other arbitrary socket.

        You have two server factories, one listening on 8060, the other on 8061. When you route a message from a connection to 8060, how can we possibly know which 8061 socket we should send the reply to?

        You would need some kind of registry where the individual clients tell the server which other clients they want to receive data from.

        Comment


        • #5
          My test example has another Spring Integration instance to act as wrapper to the application. At the moment it just sends "Hello world" to the bus.

          What do you mean by "which 8061 socket"? The socket 8061 is a server socket and 8061 is where it is going. The 8060 and 8061 are just arbitary numbers which will hard coded into the server and the clients .

          Comment


          • #6
            I think you are misunderstanding my point.

            You have 2 server sockets; a client connects (presumably) to both of them - on 8060 and 8061.

            The way you have it configured, you are receiving a request on a socket connected to 8060 and trying to send it to "some other" socket connected to 8061 - there is no way the framework can know how to determine which 8061 connection to send the reply to (even if there's only one).

            Again, if you can explain exactly what you are trying to do, including much more detail about the client, I might be able to help; but what you have right now will never work.

            Comment


            • #7
              Most "normal" TCP applications receive the reply on the same socket as the request. If that's what you want to do, simply wire the ServiceIn factory into both the inbound and outbound adapters; you don't need ServerOut.

              Comment


              • #8
                Thanks, that makes more sense. I currently have one client per port with the end goal being client->bus->another-client. Doesn't each client need its own port to connect to the server?

                The client is just a simple hello world example with a TCP inbound and a channel where there is some Java to print out the message string.

                Comment


                • #9
                  No; multiple clients can connect to the same port (e.g. 8060); the framework takes care of ensuring replies go back down to the right client.

                  Comment


                  • #10
                    Ah, ok. My example now accepts multiple client connections .

                    Is it possible to send the message to mutlple clients with TCP or do I have to use mutlicast and UDP? I have tried using the publish-subscribe channel to accomplish this usin TCP, but I have soemthing wrong.

                    Comment


                    • #11
                      Not easily - you would have to have each client register interest by sending a message to the server, and capture the ip_connectionId header (ip_connection_id on 2.1 and below) from each client. You would then need some custom code to broadcast the message to each client that has registered interest and insert it's connection id in the header.

                      Just adding a publish-subscribe-channel won't work at all.

                      We do have an open JIRA issue to support multicasting over TCP but it's not scheduled to be worked on any time soon. Feel free to add your use case as a comment on the JIRA. https://jira.springsource.org/browse/INT-2495

                      Comment

                      Working...
                      X