2-way TCP operator

[leongor]

Currently Streams has only 1-way TCP operators. Two years ago I've developed for some PoC TCPDynamicSink operator. It's main goals are:

1. To manage open connections dynamically, allowing to pass destination address as a parameter.
2. A single connection can handle 2-way communication. Only blob type was supported and max size was as a single TCP packet size. Do you think it can be interesting to publish it here?

[chanskw]

Do you think it will be a useful addition to this project here? https://github.com/IBMStreams/streamsx.tcp

I am also curious as to why you wanted a single operator with a 2-way communication? Would having TCPSource and TCPSink in an application solve this problem? What is it that this operator can do, and cannot be achieved by two separate operators?

[jchailloux]

I had to create my own in Java to be able to have an authentication (AIS). As a client you have to connect to the server but you also have send some authentication strings to the server. The 2-way could then handle a dialogue and an heartbeat with a beacon for example.

+1 for TCPSource with an input port (message to send) might be good

[leongor]

2-way TCP operator can be useful if you need to connect to existing "TCP server" that sends you responses over the same connection (so you cannot use TCPSource because the "TCP server" is not going to create a new connection). Actually, the challenge was to put Streams in the middle of application client/server 2-way communication without rewriting neither client nor server side code. So additionally to creating TCPDynamicSink operator I've added the same fuctionality to the MultiConnectionTCPServer. Thus Streams was acting as TCP proxy between multiple clients connected to multiple servers using 2-way TCP connections.

[chanskw]

+1 Thanks for the explanation.

Do you think this fits in the streamsx.tcp project? That project contains a multi-connection TCPServer.

[leongor]

Yes, it seems that it fits by it's nature, because like TCPServer it can handle multiple connections. Imagine that someone wants connect Streams to tens or even hundreds TCP nodes - it's extremely hard when using static parameter because it requires to compile stream/s with huge number of TCPSinks and then manage the routing and all other problems like failover and etc.

[ddebrunner]

Would it make sense to merge streamsx.tcp into streamsx.inet? On first seeing this operator I thought it would go into inet, which is for Internet standard protocols.

Guess I should look at the scope of tcp, first I've heard of it.

[mikespicer]

+1 for adding this to streamsx.tcp (or merging tcp into streamsx.inet), I don't think it warrants a separate repository.

[hildrum]

+1

[chanskw]

Ok... Closing the voting for this issue.

Proposal: Contribute the new operator to streamsx.tcp project so all tcp-related functions are in that toolkit.

We will look at merging the two toolkits (inet and tcp) in the future. But initially, I think all tcp functions should be in the streamsx.tcp toolkit.

Keeping this open for 1 more day. Please let us know if there is any objection.

[jchailloux]

Looks fine for me. having inet.tcp, inet.udp, inet.tcp.ftp,...... really make sense if we are able to share code using some common parts When created let us know to start discuss about the way it will work.

[chanskw]

The project is already created. You may create a pull request and contribute the new operator here: https://github.com/IBMStreams/streamsx.tcp

[chanskw]

Closing. Work is underway in the streamsx.tcp project.