2

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?

  • If you do HTTP, I would not recommend SOAP. SOAP vs REST – Kasey Speakman Oct 2 '15 at 20:05
  • Thank you for your link. I read that info and i think we might use REST. – varstas Oct 6 '15 at 8:31
  • Here's another good one. Consider just using what you need from the spec. E.g. for message/event-based APIs, I mostly only use POST and GET verbs with URIs as use cases. For CRUD/object APIs, the full spec makes more sense. – Kasey Speakman Oct 6 '15 at 13:51
0

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.

  • Actually biggest issue that comes to our mind is 2 ways communication. It's easy to establish that kind of communication with TCP, but providing that with a web service is hard. Since web services operates on request/response. What should we do if we need to send data to server without server request? – varstas Oct 6 '15 at 8:12
  • Have the server (on startup?) send out an initial request to each device. That will let the devices know where to report back to. Another method I've see is using a custom DHCP option which points back to the server. – Kasey Speakman Oct 6 '15 at 13:30
  • So you are suggesting long pooling. Thank you for your help, but i'm not sure if long pooling is the best solution. Maybe i should learn more about WebSockets. – varstas Oct 6 '15 at 13:39
  • No, I was not suggesting long polling. Assuming the server knows about the devices, but the devices do not know of the server, have the server send one command to each device RegisterMeAsYourServer. Then the device saves the info from that command. When it needs to report back, it uses info from that command to make it's own HTTP request to the server. – Kasey Speakman Oct 6 '15 at 13:55
  • Websocket is a great technology. It is still a bit young yet and doesn't yet have as widespread of support as I would like. – Kasey Speakman Oct 6 '15 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.