Janto Dreijer wrote: > Grant Edwards wrote: > >>On 2006-09-15, Janto Dreijer <[EMAIL PROTECTED]> wrote: > > .... > >>>Would it be a reasonable solution to initiate a TCP connection >>>from the client to the server and somehow (?) let the server >>>figure out how the client is connecting? And then send UDP to >>>client over the same (IP, port)? >> >>I doubt that will work unless the firewall has been >>specifically designed to recognize that pattern of activity and >>allow the incoming UDP packets. I don't think most firewall >>have default rules that allow UDP packets to tunnel back along >>a TCP connection. > > > Thanks for the info! > > I think you may be right. I had to configure the local firewall to > allow all connections from the server. Which kinda defeats the purpose. > If you have control over the NAT why not just assign a dedicated port? > > There might still be value in this approach, however. Even though I > have control over the NAT I have multiple clients that might need to > create these connections. I would need to map ports to be able to > handle simultaneous connections. > > It's Friday afternoon over here, so I may be wrong... > Note that TCP and UDP port spaces are disjoint, so there's no way for TCP and UDP to use "the same port" - they can, however, use the same port number. Basically the TCP and UDP spaces have nothing to do with each other.
Most dynamic NAT gateways will respond to an outgoing UDP datagram by mapping the internal client's UDP port to a UDP port on the NAT gateway's external interface, and setting a converse mapping that will allow the server to respond, even though technically there isn't a "connection". The NAT table entries will typically be timed out after a short period of non-use. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
