Using SI TCP\IP to have a VISA1 communication dialogue with a TCP host

[watts]

I have a similar situation to question posted on '123118-Can-i-use-two-serializers-with-my-TCP-IP-adapter' thread, but in the communication between server and the client differs; where the server can send a response after another without client submitting a request to the server (this is simply VISA1 protocol).

I tried to implement this with a gateway, using custom serializer, TCP outbound gateway, and even with TCP interceptor to handle the initial handshake (ASCII control characters) before data can be sent by the client. Also tried the idea of using channel adapters.

The question is on how can i apply spring TCP integration to handle VISA1 communication dialogue, where per connection, a stateful communication occurs in a known sequence (with server consecutively sending responses). Any idea on this area would be helpful.

Thanks in advance

[Gary Russell]

I'd have to know more about the protocol to advise the best approach but, typically, if the server can send unsolicited messages at any time, then the gateway is not appropriate (it is for purely request/response scenarios); you would need to use a pair of collaborating channel adapters. You just have to keep a handle to the connection id (from the message header) to send the unsolicited messages.

If the "extra" responses are only during handshake, you should be able to achieve that with a custom (de)serializer and possibly a connection interceptor, and the gateway should work ok.

The WebSocket extension (https://github.com/SpringSource/spri...-ip-extensions) uses the collaborating adapters approach for full asynchronous communication after handshaking is complete. It uses a combination of custom (de)serializers, an interceptor, and a custom TCP message mapper (to add additional headers without having to copy the message in the interceptor). The interceptor itself also sends out unsolicited messages (PINGs) when there has been no activity on the socket. The project also introduces the concept of a stateful deserializer (WebSockets switches from initially using HTTP) and the interceptor uses that state when decoding messages. Finally, this extension uses the new TCP eventing mechanism to alert the application when a new handshake is complete - allowing the server to send outbound messages before it receives any requests.

The test case (WebSocketServerTests) sends unsolicited messages to the browser (ws.html) after the hanshake is complete.

It doesn't have much in the way of java docs right now so let me know if you have any questions.

Depending on how complicated your protocol is, you may not need the full sophistication used there but, hopefully, it points you in the right direction.

Hope this helps.

If you think the solution will have wide appeal, feel free to submit it to the extensions repository (perhaps just a pull-request to the spring-integration-ip-extensions project, where the WebSocket extension resides).

See https://github.com/SpringSource/spri...ONTRIBUTING.md

Note: this discussion is from the server's perspective; if you are the client, similar concepts apply.

[watts]

Thanks for your quick response. Due to time constraints, I've progressed on a non SI implementation, but would like to handle the scenario using SI (down the line).

The communication between server and client is detailed below (this was the information given as VISA1 protocol), and I need a TCP client to have the below dialogue.

1. client establishes connection.
2. server sends ENQ (this is part of the handshake)
3. client sends the data packet
4. sever sends ACK (2 alternate routines may occur)
   
   1. server may send ENQ. when that happens, the client retries the server for a preconfigured number of attempts till the server sends either ACK or NAK
   2. server may send NAK, then the client needs to retry sending the data packet again and wait for a ACK/NAK from server
5. server sends data packet
6. client sends ACK (or NAK if LRC didn't add up)
7. server sends EOT

Thanks for directing me to a example. I'll try the collaborating channel adapters approach and get back to you.