Science Forums: padren - Viewing Profile - Science Forums

I'm curious if this general approach would be viable for UDP management:

Overview of current technology:

Long story short, it's pretty easy to open TCP connections (such as HTTP for web viewing) and have routers automatically ensure each system behind it can send and then receive data all properly addressed. All this is pretty much automatically handled between the browser, client systems, router, firewall, and the ultimate destination server without causing problems very often at all.

Being able to have multiple clients send UDP data through a router to a server is a configuration nightmare most of the time: they don't operate in streams, so they don't maintain connections, and you usually have to set specific ports to forward to specific client systems within the local network just to get any traffic to work at all.

Proposed solution:

If an industry standard could be established, I want to know if it is possible to setup a "standardized handshake exchange" over TCP in which a client requests a "clear UDP route" to the server, and the server responds with it's own parameters, and then they agree to the mutual set of data. Basically the client sends "Hey server, I want you to send me UDP data here on port [x]" and the server says "sure, they'll come from this range of IPs, on this range of ports, and if no traffic comes through in [x] amount we'll both agree the route has expired"

The handshake only exists to exchange any dynamic parameters (like port numbers, etc) between the client/server, but mostly so the firewall/router layers within the network can eavesdrop (which is how they route data with TCP/HTTP now, iirc) and create a temporary "port forwarding entry" and actually know how to route UDP data, and how long to maintain the exception.

The key difficulty I see is that firewall and router producers would have to implement the standard, and the only way to test if a route is successful is to "try" and send data via UDP. One firewall admin may have a different idea of what is an acceptable range of remote IPs to accept UDP data from or how long it can last idle before expiration. While these can be rejected and logged in some capacity, it makes determining the reason for rejecting the "port forwarding entry" at the firewall level somewhat difficult.

Lastly, there's the issue that whatever server you are connecting to and wanting UDP data from.... has to be designed to handle both TCP and UDP data, and ensure each remote client's total handshake data is managed. Some layer has to talk via TCP to get the port info of the client for instance, so the UDP layer can use it to communicate.




Is this a viable idea?
Did I miss solutions that already exist?
Did I use entirely too many words?

Btw - nice to be back on the forums, hopefully I'll be around more