«

This is probably more of a networking question than a Python one, but
it would be nice to know if someone has done this with Python's socket
module. And besides one usually gets more information from c.l.py than
anywhere else

I have a server with a static "public" IP and a client behind a NAT. I
would like to send UDP packets from the server to the client. So what I
need to do is open up a "hole" in the NAT and let the server know the
target IP and port of the client where it can send its packets.

Now I have read somewhere that you can have TCP and UDP running on the
same port. Not sure if this is true. 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)?

Janto Dreijer a écrit :
> This is probably more of a networking question than a Python one, but
> it would be nice to know if someone has done this with Python's socket
> module. And besides one usually gets more information from c.l.py than
> anywhere else
>
> I have a server with a static "public" IP and a client behind a NAT. I
> would like to send UDP packets from the server to the client. So what I
> need to do is open up a "hole" in the NAT and let the server know the
> target IP and port of the client where it can send its packets.
>
> Now I have read somewhere that you can have TCP and UDP running on the
> same port. Not sure if this is true. 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)?

Initiate an UDP connection from the client to the server and have the
server send back the UDP packets to the address you get in the
"recvfrom" result.

Awesome! I haven't tested it on the actual server but I think it works.
Thanks!
I prefer a TCP connection solution and will post one if it works.

server.py
========
from socket import *
print "listening"
UDPSock = socket(AF_INET, SOCK_DGRAM)
UDPSock.bind(("localhost", 1234)) # visibility to outside world
payload, addr = UDPSock.recvfrom(1024)
print "message from %s: %s" % (`addr`, payload)
UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
result = UDPSock.sendto("your public address is %s" % `addr`, addr)

client.py
=====
from socket import *
UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
result = UDPSock.sendto("what's my public address?", ("localhost",
1234))
payload, addr = UDPSock.recvfrom(1024)
print payload

results:
====
listening
message from ('127.0.0.1', 32787): what's my public address?

your public address is ('127.0.0.1', 32787)

On 2006-09-15, Christophe <> wrote:

> Initiate an UDP connection from the client to the server and
> have the server send back the UDP packets to the address you
> get in the "recvfrom" result.

There's no such thing as a "UDP connection", so I don't
understand what you're suggesting.

--
Grant Edwards grante Yow! By MEER biz doo
at SCHOIN...
visi.com

On 2006-09-15, Janto Dreijer <> wrote:

> I have a server with a static "public" IP and a client behind a NAT. I
> would like to send UDP packets from the server to the client. So what I
> need to do is open up a "hole" in the NAT and let the server know the
> target IP and port of the client where it can send its packets.
>
> Now I have read somewhere that you can have TCP and UDP running on the
> same port.

True.

> Not sure if this is true.

It is.

> 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.

--
Grant Edwards grante Yow! Clear the
at laundromat!! This
visi.com whirl-o-matic just had a
nuclear meltdown!!

Oops. That second UDPSock = socket(...) in the server.py shouldn't be
there.

Janto Dreijer wrote:
> Awesome! I haven't tested it on the actual server but I think it works.
> Thanks!
> I prefer a TCP connection solution and will post one if it works.
>
> server.py
> ========
> from socket import *
> print "listening"
> UDPSock = socket(AF_INET, SOCK_DGRAM)
> UDPSock.bind(("localhost", 1234)) # visibility to outside world
> payload, addr = UDPSock.recvfrom(1024)
> print "message from %s: %s" % (`addr`, payload)
> UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
> result = UDPSock.sendto("your public address is %s" % `addr`, addr)
>
> client.py
> =====
> from socket import *
> UDPSock = socket(AF_INET, SOCK_DGRAM) # open UDP socket
> result = UDPSock.sendto("what's my public address?", ("localhost",
> 1234))
> payload, addr = UDPSock.recvfrom(1024)
> print payload
>
> results:
> ====
> listening
> message from ('127.0.0.1', 32787): what's my public address?
>
> your public address is ('127.0.0.1', 32787)

Grant Edwards wrote:
> On 2006-09-15, Christophe <> wrote:
>
> > Initiate an UDP connection from the client to the server and
> > have the server send back the UDP packets to the address you
> > get in the "recvfrom" result.
>
> There's no such thing as a "UDP connection", so I don't
> understand what you're suggesting.

I think he means "connection" as in "associated ip/port". Which
actually does work, as I've posted.

Grant Edwards wrote:
> On 2006-09-15, Janto Dreijer <> 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...

Janto Dreijer wrote:
> Grant Edwards wrote:
>
>>On 2006-09-15, Janto Dreijer <> 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

Steve Holden wrote:
> 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.

So are you saying one can't use TCP to punch a hole for UDP?