We are trying to establish a 6LoWPAN network.
Our Devices have only the 6LoWPAN connection so we need a bridge to connect them to CMS server. A small computer (something like BeagleBone) which runs Linux acts as a bridge and communicates with multiple devices via 6LoWPAN and provides TCP connection to server.
In this bridge we have some applications which provide APIs for controlling and getting data from our devices. For now it's a bit of a dummy network. Bridge gets requests from TCP and transfers them to devices.
By the way, devices not only respond to requests but also send notifications whenever an alarm situation happens.
Now we want to make the bridge smarter. We're thinking to develop a web service on the bridge and provide some functionality (like Configuration, Scheduled Control, Group Management etc.).
It won't be a problem to provide a SOAP based web service on the bridge. But we are not sure if we should develop a web service for our network.
Is opening a TCP connection from the server to all bridges a better approach or communicating to bridges via web service a better approach?
Best Answer
For your particular use case, I would think HTTP communication would be a better fit than TCP.
In general, the main reason I would choose TCP over HTTP would be when performance was paramount and you could maintain an active connection. You can also send data both ways. With TCP, you are in more or less full control of what gets sent over the wire. (But if you use anything fancy, you have to be sure that you can put your custom code on the other end to read it.)
However, it could be too much to expect the bridge to maintain a TCP connection. (Are we talking wifi links to the bridge?) Whereas HTTP is request/response, so it just needs to be stable long enough to send and receive. (Idempotent messages are a good idea regardless.) HTTP will scale better than active TCP connections if there are many controllers. HTTP has ubiquity -- there are many HTTP servers available, and just about any language and platform can submit an HTTP request with little effort. HTTP is potentially easier to debug since you can examine the wire format (text) with human eyes.
Many of the same advantages and disadvantages of TCP can be had with WebSocket, so long as your devices can use it. One advantage of WebSocket over TCP is that most firewalls don't block the HTTP port used by WebSockets whereas your chosen custom TCP port might be blocked.