One Touch Out DAT -> Many Touch In

General TouchDesigner Discussion
1

Hi, all!

Quick sanity check: is it possible to have one Touch Out DAT that several Touch In DATs connect to over TCP? I was under the impression that Touch Ins act as clients and listen to changes from the Out, which could serve many. It seems to work in practice, just wondering if there is any reason I shouldn’t from a network architecture perspective. The documentation just says Touch Out sends data to “another process.”

Thanks!

1 Like
2

Hi @goto10 - one thing to keep in mind is that TCP/IP connections are “reliable”. In network terms this means that messages are guaranteed to be delivered in the right order from server to client. For many use cases this works well, but there are some cases where a reliable connection may mean that different clients receive the messages at different times. Unreliable connections (like UDP connections) aren’t guaranteed to be delivered or to be delivered in the right order but tend to have fewer issues with latency.

Both types are useful, and TouchOut OPs can be configured as TCP/IP or UDP based.

The article on Network Protocols is worth looking over as you think about what connection type is going to be right for your project:

3

Yes, an emphasis on the “reliable” quotation marks in Touch environments. For whatever reason I always seem to end up going UDP instead of TCP for just about every networked project, even on managed switches in what appear to be well tuned network environments. It’s not so much that the TCP message arrives at a different time… it’s that it sometimes never arrives at all. Something appears to start blocking it at some point, after which only a restart resolves.

Are there any network engineers that speak TouchDesigner, who could chime in? I’ve been longing for an answer to @goto10’s question for a long time… a long time.

1 Like
4

Thanks, Matt!

I do think TCP is better in this case, reliability > latency in this case. The Networking protocols doc seems to say touch in / out can have multiple clients (but doesn’t specify if thats true for all the protocols it supports), and it does say TCP can send to multiple clients at once (but it doesn’t say if that applies to the Touch In / Out DAT). Seems promising, I’d just love to have a definitive “yes, Touch In/Out is designed to work that way” sort of answer.

Thanks again for the response! And hi, Dylan!

1 Like
5

Hey @dylanroscover what you describe sounds very much like a network port being blocked by an already dead TCP/IP listening process which can’t be killed anymore.

I’ve encountered this very often during (TD/Python) development on Windows when working on multiple applications/processes who talk to each other over the network.
In my research this can happen when the parent crashed but connection was opened by either child process or parentprocess of the -now non-existing- processid, or port ownership was passed on during that crash.
Anyway some process was killed while windows thinks that port is still in use, meaning the port is now still blocked by the Windows OS. Which explains why it can always be solved when rebooting/ logging out.(as you already discovered).

The only thing I found which works is the windows CMD commands below.
So I converted these commands into a Python method which is now always called before trying to make a connection, the code then auto-finds and kills any process id which would be blocking any of the ports of my project, and after that tries to make a connection. This method solved all my network issues.

So the CMD commands are:

  1. First find the process that is causing the issue, suppose we are trying to connect on port 3000:
netstat -abno | findstr /i "listening"| find ":3000"
    TCP    0.0.0.0:3000           0.0.0.0:0              LISTENING       3116
  1. now find the parent process id
wmic process get processid,parentprocessid | findstr/i 3116
    3116             23828
  1. now find all the children process ids from that parent we just found
wmic process where (ParentProcessId=23828) get Caption,ProcessId
    Caption        ProcessId
    wireguard.exe  27400
  1. Kill all processes starting from the child processes to the parent process
taskkill /f /pid 27400 
taskkill /f /pid 3116 
taskkill /f /pid 23828

These issues only happened on my development machines, never in production, so I concluded that it usually only happens when you start/kill processes very often&fast during development, and then once in a while windows is not capable of syncing/cleaning up its ports list.

See here the thread where I found this info

4 Likes