Mirth Connect
  1. Mirth Connect
  2. MIRTH-2446

Add a "server mode" to the TCP Sender connector

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0, 3.0.1, 3.0.2
    • Fix Version/s: 3.9.0
    • Component/s: Administrator, Server
    • Labels:
      None

      Description

      This stemmed from a very interesting conversation on the forums: http://www.mirthcorp.com/community/forums/showthread.php?t=3818&page=3

      This would be very similar to how the TCP Listener has a "client mode". Basically instead of the TCP Sender always initializing the socket, it would prop up a server socket and wait for a client to connect. Once that happens, all other behaviour would remain the same. If messages are slated to be dispatched and a client has not yet connected, they would be queued (or errored out if queuing is disabled).

        Activity

        Hide
        Neils Schoenfelder added a comment -

        The idea of 2 separate open TCP server ports on Mirth (one port to create persistent 'sending-server' sockets, and one port to listen for 'registration' requests) is clever. Paraphrasing:
        A. The external client could receive a unique "subscription token" when it connects to the 'sending-server' port.
        B. Then the client could send that "subscription token" along with info about itself (like what information it wants to subscribe to) back to the 'registration' port.
        The uniqueness of the subscription token would allow the info the client sent in step (B) to be correlated with the TCP socket connected to in step (A).

        I'm not sure I agree that all clients connected to the channel should get the same information, though. It seems like the pool of connections would be associated with a single 'destination' in the Mirth channel. This makes it sound reasonable that the Filter and Transformer code for the destination could be made to run once for each TCP socket, rather than just once for the entire destination. That makes it fairly trivial to allow individual sockets to send a subset of the overall information. In other words, Mirth could send messages to clients in a round-robin style for load balancing, in a broadcast style for alerting all clients to an event, or in a a filter-by-message fashion for pub/sub messaging.

        Show
        Neils Schoenfelder added a comment - The idea of 2 separate open TCP server ports on Mirth (one port to create persistent 'sending-server' sockets, and one port to listen for 'registration' requests) is clever. Paraphrasing: A. The external client could receive a unique "subscription token" when it connects to the 'sending-server' port. B. Then the client could send that "subscription token" along with info about itself (like what information it wants to subscribe to) back to the 'registration' port. The uniqueness of the subscription token would allow the info the client sent in step (B) to be correlated with the TCP socket connected to in step (A). I'm not sure I agree that all clients connected to the channel should get the same information, though. It seems like the pool of connections would be associated with a single 'destination' in the Mirth channel. This makes it sound reasonable that the Filter and Transformer code for the destination could be made to run once for each TCP socket , rather than just once for the entire destination. That makes it fairly trivial to allow individual sockets to send a subset of the overall information. In other words, Mirth could send messages to clients in a round-robin style for load balancing, in a broadcast style for alerting all clients to an event, or in a a filter-by-message fashion for pub/sub messaging.
        Hide
        Nick Rupley added a comment -

        First, a client would not be able to receive a subscription token just by connecting to the "sending-server" port. That is a destination connector, and without a message processing through the channel to trigger it, a connecting client would not receive anything at all. The whole point of the registration port is to provide a way for the client to push initial data to the server and/or receive initial data.

        Second, a pool of connected clients would be associated with a single destination connector. As such, when a message processes through, it would be dispatched to all connected clients for that destination. If you like you can create separate destinations for separate clients, but obviously those server sockets would be bound to different ports.

        For a single destination connector, the filter/transformer would not be run for each socket that happens to be currently connected. The job of the dispatcher (TCP Sender) is to take the output of the transformer (encoded data) and send it out to a downstream system. The transformer has no knowledge whatsoever of the dispatcher, what kind it is, how many sockets are connected if it happens to be a TCP Sender, etc

        You can already do round-robin message dispatching with the TCP Sender by using a Velocity template variable in the address/port fields. If and when we add the new "server mode" feature, then you automatically have the broadcast-style alerting. If we added the "allowed addresses" field for server mode, then you can do the filter-by-message style for pub/sub.

        We are considering adding a new "re-run the filter/transformer on each queue attempt" feature. If you leverage that, the variable address/port replacement, and the response transformer, then you could technically run the transformer for each specific socket and dispatch a message only to that socket using the "allowed addresses" field.

        Show
        Nick Rupley added a comment - First, a client would not be able to receive a subscription token just by connecting to the "sending-server" port. That is a destination connector, and without a message processing through the channel to trigger it, a connecting client would not receive anything at all. The whole point of the registration port is to provide a way for the client to push initial data to the server and/or receive initial data. Second, a pool of connected clients would be associated with a single destination connector. As such, when a message processes through, it would be dispatched to all connected clients for that destination . If you like you can create separate destinations for separate clients, but obviously those server sockets would be bound to different ports. For a single destination connector, the filter/transformer would not be run for each socket that happens to be currently connected. The job of the dispatcher (TCP Sender) is to take the output of the transformer (encoded data) and send it out to a downstream system. The transformer has no knowledge whatsoever of the dispatcher, what kind it is, how many sockets are connected if it happens to be a TCP Sender, etc You can already do round-robin message dispatching with the TCP Sender by using a Velocity template variable in the address/port fields. If and when we add the new "server mode" feature, then you automatically have the broadcast-style alerting. If we added the "allowed addresses" field for server mode, then you can do the filter-by-message style for pub/sub. We are considering adding a new "re-run the filter/transformer on each queue attempt" feature. If you leverage that, the variable address/port replacement, and the response transformer, then you could technically run the transformer for each specific socket and dispatch a message only to that socket using the "allowed addresses" field.
        Show
        Nick Rupley added a comment - http://www.mirthcorp.com/community/forums/showthread.php?t=15386
        Hide
        Terry Waldron added a comment -

        I'm looking to use "server mode" on a TCP Sender connector for HL7v2.x. Can you make any suggestions on how I can do this?

        Show
        Terry Waldron added a comment - I'm looking to use "server mode" on a TCP Sender connector for HL7v2.x. Can you make any suggestions on how I can do this?
        Hide
        Nick Rupley added a comment -

        This could be done in a different way, such as having a socket resource that would have client/server mode, and both listeners and senders could use.

        Show
        Nick Rupley added a comment - This could be done in a different way, such as having a socket resource that would have client/server mode, and both listeners and senders could use.

          People

          • Assignee:
            Nick Rupley
            Reporter:
            Nick Rupley
          • Votes:
            28 Vote for this issue
            Watchers:
            18 Start watching this issue

            Dates

            • Created:
              Updated: