I am woking on a Mobile application, which sends GPS co-ordinates from the mobile to an azure website.
Right now I am able to do this using TCP endpoints in Azure Web/Worker Role. The Mobile hardware I am using is SIM300 module.
SIM300 also provides sending data via UDP, which is much simpler, faster for my application.
I have heard Azure Connect uses UDP to communicate between local and virtual machines through UDP.
I am not sure, but is there any way to implement the same application to use UDP instead of TCP in Azure?
I managed to get UDP to work over the service bus using a UDP -> TCP tunnel. But as Simon says, you're better off using TCP if you can.
http://coderead.wordpress.com/2012/03/14/tunnelling-udp-over-the-service-bus-or-how-to-get-sentinel-licencing-server-working-on-azure/
Azure doesn't support public UDP endpoints (yet). The only current alternative is to use an non-Azure server that listens on UDP and, via Windows Azure Connect, forwards it to the 'internal' endpoint. Since your device already uses TCP anyway, I would stick with that for now.
Related
I'm currently developing a "node-based" system where a server will send out a UDP broadcast on the private network (with a custom protocol), which will be received by several different clients which supports the specified protocol. The server will after the request pick between some of the clients for a more steady TCP connection.
Request for client sequence
Server broadcasting a request-for-ip message to every device/node on the network.
All available clients that supports the protocol will answer with their unique IP to the server.
Server chooses among the clients via a request-for-connection message.
Client that got choosen by the server connects to the server via TCP for a reliable connection.
My question
I've got pretty good knowledge about both TCP and UDP, but I've never designed a system like this before. Do you think this system is built in the right way or is there a more "standard" way doing something similar to this? What are your thoughts?
Thanks!
--- Edit ---
Added a diagram of the program.
There is a standard protocol to advertise services on the network, which you may like to consider: Simple Service Discovery Protocol, based on periodic UDP multicast:
The Simple Service Discovery Protocol (SSDP) is a network protocol based on the Internet protocol suite for advertisement and discovery of network services and presence information. It accomplishes this without assistance of server-based configuration mechanisms, such as Dynamic Host Configuration Protocol (DHCP) or Domain Name System (DNS), and without special static configuration of a network host. SSDP is the basis of the discovery protocol of Universal Plug and Play (UPnP) and is intended for use in residential or small office environments.
In this protocol clients join that UDP multicast group to discover local network services and initiate connections to them, if they wish to. And this is pretty much the intended use case for the protocol, which is somewhat different from your use case.
One benefit of IP/UDP multicast is that multicast packets can be dropped in the network adapter if no process on the host has joined that multicast group. Another one is that IP/UDP multicast can be routed across networks.
From the diagram you posted:
The server is the mediator (design pattern) whose location must be known to every other process of the distributed system.
The clients need to connect/register with the server.
Your master client is a control application.
It makes sense for the server to advertise itself over UDP multi-cast.
Online clients would connect to the server using TCP on start or TCP connection loss. If a client terminates for any reason that breaks the TCP connection and the server becomes immediately aware of that, unless the client was powered off or its OS crashed. You may like to enable frequent TCP keep-alives for the server to detect dead clients as soon as possible, if no data is being transmitted from the server to the clients. Same applies to the clients.
All communications between the server and the clients happen over TCP. Otherwise you would need to implement reliable messaging over UDP or use PGM, which can be a lot of work. Multicast UDP should only be used for server discovery, not bi-directional communication that requires reliable delivery.
The master client also connects to the server, possibly on another port, for control. The master client can discover all available servers (if there is more than one) and allow the user to choose which one to connect to.
We are investigating adding the Kaa client to our products and using the Kaa server operationally, and we have some questions in the networking and protocol area. Our main concern is having the IoT device access the IoT server through the Internet without being blocked by the firewall at the IoT device in a "typical" environment. For this reason we see that HTTP/HTTPS using port 80/443 is often used.
Do you believe that most of the IoT device will communicate because most firewalls allow all outgoing traffic?
Or do you think that most end users will have to explicitly configure a firewall rule for the IoT device?
What was the rationale for using the port numbers 9889/9888 and 9999/9997?
Can these port numbers be reasonablely modified? If so, where and how?
Is there a specification of the Kaa TCP protocol?
Thank You
Keith Krajewski
About Kaa TCP protocol use official documentation page
you can change ports of bootstrap and operations services in this files:
bootstrap-http-transport.config
bootstrap-tcp-transport.config
operations-http-transport.config
operations-tcp-transport.config
I am trying to create a small academic project in the area of home automation. I explored various protocols and standards in IOT domain and find COAP close to my requirements.
The intent is pretty simple: To have a peripheral at home (like bulb, temperature sensor etc) which act as COAP server and expose certain resources and services. Since COAP uses an addressing scheme similar to web, any client having the address of this server shall be able to talk to this COAP server (i.e. peripheral) and control its attributes.
I have certain doubts about how a client not present in the same LAN as the server, can discover this server and the resources exposed by it. I understand that COAP facilitates resource discovery using CoRE link format but it seems that it primarily uses multicast which can only work within a LAN. I don't want to put a resource directory server at home and various COAP servers registering with it and then this directory server talking to a server sitting in the cloud. I want to have the ability to just install a peripheral at the home which can communicate to a remote client (like COPPER) using wifi home network. But how to discover the COAP server sitting at home from a remote location and then talk to it considering that COAP server will be on a private IP address.
Is this really possible using just COAP?
As you're sitting behind a NAT, that will allow neither direct discovery nor connections; CoAP will not try to magically pierce that.
Popular ways out are:
Use IPv6 (obliviating the use of a NAT) and (at least selectively) disable the firewall. You will still only be able to do discovery locally, but once discovered, you can connect to your devices from anywhere.
Use a VPN to make your mobile device act as if it were in the NAT.
Run a CoAP proxy at the router with a port open to the outside, and tell your mobile device to connect through that proxy. This does not give you local discovery either.
For the proxy and IPv6 cases, you can then still run a resource directory in your local network. That does neither need to connect to nor accept registrations from any cloud service, but it can help you do the very discovery that you'd like to do with multicast but can't because your mobile device is too far away. Both the resource directory and the proxy should be configurable to not talk to devices outside the local network unless they are authenticated.
Make your router accept HTTP requests , and run a HTTP to CoAP proxy in your system, access your CoAP devices via your IP thought HTTP-CoAP proxy.
I have been looking for an answer to this problem, but I cannot find what I am looking for. I think, perhaps, it is because I lack the knowledge to ask the question in meaningful way.
I have been learning a lot about remote access to devices at home. I know that ISP's change public IP addresses regularly (dynamic IP address). I know that to get around this, one could use a service like "no-ip", etc. Or one could get a static IP address.
What I do not understand is how some of the latest home automation devices are able to be controlled remotely without use of a static IP, or a service like "no-ip". For example, a wifi enabled thermostat, or lighting system.
If the device had a built in server, or client, then I assume that the device could connect to an outside server in a remote location. The user could then also log into that server and send commands to the device. What I don't understand is how commands sent to the device from a cell phone, for example, can reach the home device. Presumably the off site location of the server would have to know the public IP address where the devise is located, and then port-forwarding would have to be set up to allow access to the device.
What am I missing here? Is it possible to create a homemade wifi enabled thermostat, webcam, or other device without using port-forwarding, no-ip, or a static IP?
Well, there are several ways to bypass the inbound connection constraint of NAT protocol. Such as:
A virtual adapter on the device configured to a VPN server that has an inbound port open ready to transfer data. Various open source solutions such as openVPN are considered as great examples for this service over IOT boards like Raspberry Pi, Beagle Bone, etc. These are used as gateways often. Further, they communicate with the microcontrollers over popular IOT protocols such as MQTT, COAP, etc.
Another solution is to create a port forwarding tunnel, since the router won't block the outbound connection. There are various tunneling services that are availble such as localtunnel, ngrok, etc. You could also use a cloud server that has a public IP such as AWS, DigitalOcean, etc. Again as above mentioned point, they can be implemented in the gateways.
Some devices "phone home" to a server so that there are ports open between them and the servers, and the mobile apps just contact the servers. This is the same way your web browser can receive web pages from a web server. If you have a NAT router, the router must open a port from the inside device to the outside server. This is maintained in a NAT table with expiration timers for UDP and session monitoring for TCP.
Assuming there is a client-server application running in a LAN. Clients are WPF applications and the server is a Windows service. Are there any benefits to use Websockets instead of raw TCP sockets for client-server communication?
No. The primary benefit of WebSockets in general is that they are available in web browsers. If your application is not running in a web browser, there is no point in using WebSockets.