UDP Packets on shared host / cloud

DublinDilbert

Hi All,

Am looking at doing a mini project that would use UDP packets, at this stage its just a proof of concept, but would like to demo it working across the internet. I know most shared hosts just allow regular port 80 TCP traffic. Where as I would like to be able to open up a port and listen for UDP.

Ideally I'd like to use the .net frame work but would be open to other suggestions. I know i could do it using a machine at home and setting up dyna dns, port forwarding etc, but would like to use something int he cloud.

Is there any services that will take in UDP data and forward it on to a webservice etc?

Thanks,
D

srsly78

Use .net sockets to deal with udp and convert it to something else and forward it. UDP is pretty low level, it's best to DIY in this case.

DublinDilbert

srsly78 wrote: »

Use .net sockets to deal with udp and convert it to something else and forward it. UDP is pretty low level, it's best to DIY in this case.

I've no issue using sockets in .net. I'm just looking for something in the cloud that could be configured to handle the udp traffic and forward it on, to say a webservice on my shared hosting.

srsly78

Well you can choose any port you want. Just make sure they have a range of udp ports open. Shouldn't be a problem tbh. Lots of stuff uses UDP, especially games for example. Anything that can host game servers would do you fine.

DublinDilbert

Yep lots of systems udp, everything from msn, skype to bit torrents... I know if I pay for a dedicated server or host it myself I can accept udp packets.

jimmycrackcorm

All you need is a dedicated ip address.

DublinDilbert

jimmycrackcorm wrote: »

All you need is a dedicated ip address.

I want to avoid hosting it at home. I know i could do it at home and forward ports etc, but i'm looking for a cloud solution.

techguy

You'll more than likely need a dedicated server or a VPS at least.

I'm pretty sure no shared host will allow this, security issues etc aside, probably just to push you towards vps or dedicated.

For a proof of concept your probably better off setting it up at home rather than splashing out on hosting.

ianhobo

DublinDilbert wrote: »

Yep lots of systems udp, everything from msn, skype to bit torrents... I know if I pay for a dedicated server or host it myself I can accept udp packets.

You can probably access UDP packets anyway, they are usually not restricted, the problem is the ports being used. There no reason you can't sent UDP packets to port 80, the problems is that *usually* it's a webserver expecting a TCP connection.


1) Why can't you use TCP on port 80? (Have your data as the packet contents, then process or ship off to another server (This can even be UDP packets, TCP is only a header extension))
2) Have you looked at maybe tunneling the connection over port 80?
3) Maybe you could use the ports usually used for RTP/RTSP, they can often be opened.
4) Explicitly check what ports are open/closed on your free system. Free hosting will often have other ports open too (ssh, ftp, https. SMTP, etc), have you asked their support about available or general usage ports?

For your demo, does the client have to be in the client? How about an android or iPhone client app, lots of port control there...

If none of that is usefull, maybe explain your problem in a bit more detail

DublinDilbert

techguy wrote: »

You'll more than likely need a dedicated server or a VPS at least.

I'm pretty sure no shared host will allow this, security issues etc aside, probably just to push you towards vps or dedicated.

For a proof of concept your probably better off setting it up at home rather than splashing out on hosting.

Yea thats what i'm kinda thinking myself. Just wanted to check to see if there was anything out there that would forward UDP packets onto a web-service for me....

DublinDilbert

ianhobo wrote: »

You can probably access UDP packets anyway, they are usually not restricted, the problem is the ports being used. There no reason you can't sent UDP packets to port 80, the problems is that *usually* it's a webserver expecting a TCP connection.


1) Why can't you use TCP on port 80? (Have your data as the packet contents, then process or ship off to another server (This can even be UDP packets, TCP is only a header extension))
2) Have you looked at maybe tunneling the connection over port 80?
3) Maybe you could use the ports usually used for RTP/RTSP, they can often be opened.
4) Explicitly check what ports are open/closed on your free system. Free hosting will often have other ports open too (ssh, ftp, https. SMTP, etc), have you asked their support about available or general usage ports?

For your demo, does the client have to be in the client? How about an android or iPhone client app, lots of port control there...

If none of that is usefull, maybe explain your problem in a bit more detail

I want to be able communicate back down from the web to an embedded system, which will more than likely be behind one (or possibly more) NAT devices. Most NATs/routers will keep a table in memory that will map the UDP traffic correctly back to the original device. The idea would be that the embedded device would send up a UDP packet say every 5 mins, then at any stage if the web-server needs to contact it, it can do so by sending back a UDP packet. The main communication may well be done over TCP.

I have tried it at home on my internal network with a few layers of NAT and it works fine. I guess I could just write a C# app to handle the UDP traffic and run it on say a netbook at home, forward on the correct udp ports to it. It could also run IIS to handle the web end of it...

Thanks for the replies, all need now is time to set it up!

Webmonkey

Just wondering why you wouldn't use TCP? No guarantees on UDP, is it vital that the messages get delivered? or will you implement this check yourself checking if you get a response in time.

srsly78

Games use udp coz it has much lower latency. Also it's acceptable for the odd packet to get lost in this situation. You can use both ofc. Some messages are important but not time critical to use tcp, game world updates spam packets and need to get there fast to use udp.

Webmonkey

srsly78 wrote: »

Games use udp coz it has much lower latency. Also it's acceptable for the odd packet to get lost in this situation. You can use both ofc. Some messages are important but not time critical to use tcp, game world updates spam packets and need to get there fast to use udp.

Yeah that's my point, if you only send a packet every 5 minutes, then might as well do it with TCP

DublinDilbert

Webmonkey wrote: »

Yeah that's my point, if you only send a packet every 5 minutes, then might as well do it with TCP

Its not the sending up of packets to the web-server I'm worried about, yep I could use TCP for this. I want to be able to instantly talk back to my embedded unit, that's why i'm thinking I can shoot down a UDP packet to it. I can build into my protocol if a UDP packet gets lost anyway.

Am I looking at this the wrong way. TCP would defo be the easiest way and I can call a web-service from my embedded system and send up info. But its the sending back down of information to my system that I want.

srsly78

Why do you need speed? In 99.99% of situations it's better and easier to use tcp. Only real-time sensitive stuff needs udp.

DublinDilbert

srsly78 wrote: »

Why do you need speed? In 99.99% of situations it's better and easier to use tcp. Only real-time sensitive stuff needs udp.

I want the user to be able to interact with the remote embedded device. So when the user logs into the web-site I want to be able to communicate immediately with the embedded system. Also the embedded system will more than likely be behind a NAT so can't open a TCP port directly to it, unless I forward ports etc....

This is a real problem in machine to machine communication. You also could of a lot of client devices out in the field which you may want to contact.

srsly78

You are barking up the wrong tree, you don't need UDP at all.

Google about NAT traversal and pinholes. UDP will also get blocked by firewall/nat etc, just the same as TCP, unless you open a port.

Just use the same stuff you are thinking of with tcp and it will work fine.

ie:

Outsider initiates first part of communication, using http port 80 or whatever.
Insider then opens a new connection and a port negotiated by first part. This connection gets thru NAT coz it's initiated by the outside.

Another way is to have a 3rd party that manages the handshaking, but again the trick is the people behind the NAT initiation connection to the inside.

Game "lobbies" use this kind of stuff. Is a bit of a headache, but doesn't need udp. Sorry for bad explanation, it's been a while since I looked at this, but I did get it working.


edit: Here you go: http://en.wikipedia.org/wiki/TCP_hole_punching
You can also do the same with UDP, but you don't need udp at all - it only introduces headaches.

DublinDilbert

srsly78 wrote: »

You are barking up the wrong tree, you don't need UDP at all.

Google about NAT traversal and pinholes. UDP will also get blocked by firewall/nat etc, just the same as TCP, unless you open a port.

Just use the same stuff you are thinking of with tcp and it will work fine.

ie:

Outsider initiates first part of communication, using http port 80 or whatever.
Insider then opens a new connection and a port negotiated by first part. This connection gets thru NAT coz it's initiated by the outside.

Another way is to have a 3rd party that manages the handshaking, but again the trick is the people behind the NAT initiation connection to the inside.

Game "lobbies" use this kind of stuff. Is a bit of a headache, but doesn't need udp. Sorry for bad explanation, it's been a while since I looked at this, but I did get it working.


edit: Here you go: http://en.wikipedia.org/wiki/TCP_hole_punching
You can also do the same with UDP, but you don't need udp at all - it only introduces headaches.

Ummm I don't think i'm barking up the wrong tree at all. I know how NAT traversal works.

Can you answer me a quick question:- How come skype or MSN works without me (or anyone else in the world) opening up or forwarding UDP ports? How do 2 MSN/skype users both behind NATs connect to each other?

They use a 3rd machine which is out on the internet with a proper IP address to exchange information with each other. They also do a trick to punch holes in their own NATs by injecting out UDP packets that they know will never be delivered.

This explains the process:-
http://en.wikipedia.org/wiki/UDP_hole_punching

I've actually punched holes in NATs before using UDP, so have some experience of it and it does work. So i'm not concerned about this part, was just looking for a cloud hosting solution to receive the UDP packets but it doesn't look like there is on.

srsly78

It doesn't matter whether you use tcp or udp, you still have the same issue to solve. Read links above again. I have gotten this working with TCP alone. Yes there are some old routers with wierd NAT that screw things up, but I have never actually encountered one.

Your "3rd party" in this case is actually your webserver which is accessible, it performs the mediation.

edit: Also you might be confused about udp vs icmp vs tcp. You can punch the hole using raw icmp packets, using the methods detailed in link above. Once hole is punched appropriately you can use a normal tcp connection. You do not have to use UDP for this!!!

ianhobo

DublinDilbert wrote: »

Can you answer me a quick question:- How come skype or MSN works without me (or anyone else in the world) opening up or forwarding UDP ports? How do 2 MSN/skype users both behind NATs connect to each other?

Answer: UPnP https://secure.wikimedia.org/wikipedia/en/wiki/Universal_Plug_and_Play#NAT_traversal

Using this protocol allows the nat traversal and "automatic" port negotiation.

.....allowing any local UPnP control point to perform a variety of actions, including ... and add or remove port mappings.

So, your embedded device, with UPnP, you should be able to bind to almost any port and have UPnP manage the ports on the gateway device. At the very minimum you should be able to bind your service to port 80, its probably already open, and use UPnp to forward it to you.

So when the user logs into the web-site I want to be able to communicate immediately with the embedded system.

Great, have a socket on your embedded client listening on the port you've opened with UPnP for incoming connections. When the user access the website, either do a socket connect to your device, or perform a POST or something with your device as the target.

The only other way will be to use an intermediate device. The user actions get logged to a database or webspage, which the client device will have to poll every minute or so to read any updates. It can post its updates to the same source, which the client website can read

srsly78

You mean this: https://secure.wikimedia.org/wikipedia/en/wiki/Internet_Gateway_Device_Protocol

What was discussed above is a "roll your own" version of that. You can't guarantee that a given router will support IGDP so you for a proper generic solution you gotta do it yourself however.