I am working with an electronics appliance manufacturer to embed LAN based control systems into the products. The idea is to serve up a system configuration/control interface through a web browser so clients never need to install software. We can communicate with the appliance by sending and receiving serial data through the embedded module. Since the appliance can also be controlled from a front panel UI, it creates a challenge to keep a remote web interface in sync with very low latency. It seems like websockets or some sort of Push is what we need for handling real time events from the server to clients.
I am using a Lantronix Mathport AR embedded device server. Out of the box the unit will serve up any custom HTML and java servlets/applets. We have the option to install a lightweight Linux distro if we need more flexibility. I am not sure how to implement any server side apps since the device is not running standard Apache. I believe it is using Boa.
Can anyone guide me in the right direction of how to do this?
Some general info...The WebSocket protocol (draft spec here) is a simple layer on top of TCP. What this means is that, if you already have a TCP server for your platform, implementing the WebSocket is just a matter of hours. The protocol specifies a handshake and two ways of sending data frames.
I strongly suggest you start by reading the 39 pages spec.
As Tihauan already mentioned, start by reading the spec, and also note that there are still some changes ongoing, although websockets is now more stable than it was 1 year ago.
Key point for me was the requirement that websocket data is entirely UTF-8 text, which lends itself nicely to JSON based message definitions.
Our system uses a form of embedded linux, so we then added and made use of the following libraries:
"libwebsockets" from:
http://git.warmcat.com/cgi-bin/cgit/libwebsockets/
"jansson" from:
http://www.digip.org/jansson/
Using the above as support libraries, we created an internal lightweight "client/server" that allowed our other software modules to register for certain, applicable, websocket messages, and respond as needed. Worked great.
Good luck and best regards,
I'm a bit late, but Mozilla posted a guide entitled "Writing WebSocket servers", which literally guides you through writing a websocket server.
You will need to already know how HTTP works and have medium programming experience. Depending on language support, knowledge of TCP sockets may be required. The scope of this guide is to present the minimum knowledge you need to write a WebSocket server.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
Related
Are there currently solutions where your server can act as the peer of a WebRTC connection?
The reason I am interested in WebRTC is not the peer-to-peer part of it, but because it enables you to use UDP. You could let players participate in a fast-paced game like Quake without needing any plugins.
It seems that essentially this same question was asked before, but surely things must now be quite different as 2 years have passed.
Yes, it is possible to deploy your WebRTC peer code on server. But since you need to run it on server, it's essentially different from how you run the WebRTC code within the browser - i.e. through a Java Script.
For server based WebRTC peer, you would need to use the WebRTC native code available on platforms - Windows, Mac OS X, Linux, Android and iOS. You can get the WebRTC native code from - https://webrtc.org/native-code/development/
Follow the instructions here to download and build the environment. Sample applications are also present in the repository at the locations - src/webrtc/examples and src/talk/examples
In summary you have use the WebRTC source code that is embedded in the browser in your application code and call the relevant methods / API for the WebRTC functionality.
I have answered similar question at: WebRTC Data Channel server to clients UDP communication. Is it currently possible?
We have implemented the exact same thing: a server/client way of using WebRTC. Besides we also implemented data port multiplexing, so that server would only need to expose one data port for all rtcdata channels.
Here is 2018 update for you: your off-the-shelf solutions are:
Red 5 Pro, Wowza, Kurento, Unreal Media Server, Flashphoner
Also note that in modern public networks TCP is not much slower than UDP;
but UDP may have a considerable packet loss, so try WebRTC-TCP for your Quake idea.
I tried to build a server for integrating the webrtc native APIs in an native app, but I am not sure about how the server should be configured, like the ICE/STUN/TURN, signaling, media server etc..
So far as I know is the open source project: https://github.com/priologic/easyrtc
Can anybody give some recommendations?
Thanks
In a WebRTC infrastructure, there are several things involved. The client part is written in JavaScript and runs on the browser.
But as you said it is a server side part. First there is a ICE/STUN/TURN server that it's used for a client to discover its public IP address if it is located behind a NAT. Depending on your requirements could not be necessary to build/deploy your own server, but use an already public (and free) existing one - here's a list. You can also deploy an open source one like Stuntman.
Then it comes the signaling part, used by two clients to negotiate and start a webrtc session. There is no standard here and you have a few options.
You can use an XMPP server with a Jingle extension. You can deploy an existing XMPP server, like OpenFire or Tigase
You can also use SIP, a protocol much more encountered for VoIP. You can use JAIN-SIP or SIP Servlets.
Or you can develop your own signaling protocol using something like websockets.
The server side options that I was giving you were Java based ones, but you can find similar for other infrastructures too.
STUN/TURN is required. Use public ones (not absolutely stable) or get a Ubuntu machine ans install from the source: https://code.google.com/p/rfc5766-turn-server/
Signaling is trivial. You just forward messages between peers. Just build a simple chat server.
Media server is whole different story and require sophisticated client-server configuration.
I've spent hours now looking for an answer to this question and I can't seem to find it anywhere.
Are there any tutorials or sample code that help with setting up an http connection so that a user can use the browser to save the application coredata sqlite file to the desktop and/or send a previous sqlite backup to the app?
Thanks in advance.
You can use the Cocoa HTTP Server. I have used it before, and it works great.
It has:
Built in support for bonjour broadcasting IPv4 and IPv6 support
Asynchronous networking using GCD and standard sockets
Password protection support
SSL/TLS encryption support
Extremely FAST and memory efficient
Extremely scalable (built entirely upon GCD)
Heavily commented code
Very easily extensible WebDAV is supported too!
I am attempting to build a client/server game architecture and would like to begin testing the game using my local Mac as the server. I have found several articles on Bonjour, but that is for local network traffic only. My goal is to make this application work over the Internet, connecting to a hosted application on a static address to facilitate turn data. However, I'm at a loss as to which Cocoa APIs to use for this purpose. Should I use NSConnection, NSStream subclasses, or good 'ol C sockets and whatnot. The game state is already built in Objective-C and is ready to be set in motion once I have the server facilities ready. Any insight?
NSConnection, NSStrean and C sockets are build for different needs. You need to specify the needs of your game and the kind of service in order to get more help. If you want to develop a client-server application that relies on the Internet and not on the local network, Bonjour will not be able to help.
C sockets, and Cocoa APIs that wrap around them are intended to operate on an open network stream between the client and the server. The advantage of having an open stream is that you can have the server send data to the client without the client having requested for it. NSURLConnection in Cocoa works differently. With it, you can perform HTTP requests and receive formatted responses from a server.
If your application is based on HTTP requests, I recommend you take a look an NSURLConnection, or AFNetworking, as a 3rd party alternative. If your application relies on open streams, I recommend you take a look at CFNetwork from Apple (C wrapper around BSD sockets that originates from the days Macs had Carbon, with great performance, stability and versatility) and GCDAsyncSocket, a 3rd party library wrapped around BSD Sockets, supports Crand Central Dispatch, is Objective-C ready, and does the job wonderfully.
I hope I helped.
I suggest you to use sockets, since they're not hard to use and are a standard way. I've even written an asynchronous wrapper class around BSD sockets: https://github.com/H2CO3/TCPHelper
This is for simple, one-to-one TCP protocol connections, supporting both IPv4 and IPv6. You can send and receive raw NSData and possibly build a protocol around it.
Foundation classes such as NSURLConnection are not particularily for this purpose; rather than to interact with standard HTTP servers (I suppose you don't want to implement a full HTTP server for a game).
NSNetServices may suit you just like CFNetwork, but the latter is a bit harder to use. If you'd like to use Foundation classes, I'd recommend NSNetServices.
Hope it helps.
There are many different ways to accomplish this. It really depends on how you'll be passing the data and what it will be used for.
First, I would setup a hostname that you can use for development purposes with your game. You can use anything like http://dyn.com/dns/ to setup this for your Mac. Then you can enable a compiler setting to switch out the development / production URL's.
Next, I would recommend using TCP sockets for your game (using CocoaAsyncSocket - https://github.com/robbiehanson/CocoaAsyncSocket). This method should work fine your your use case. Since you are doing turn-based data (and since all of that data is vital) I would not recommend using UDP sockets (but those would work if you were solely passing position, video, or audio data where a dropped packet might not matter).
I am working on a project that involves an embedded system which runs a non-microsoft OS with a C program for the application and am developing .NET software for its end user applications. For remote configuring with the .NET software (which can go across firewalls), I am considering using WCF. I know only a little about WCF so far but I've read that it is supposed to be interoperable with environments other than .NET. The embedded environment has an HTTP stack but no built in support for web services. Does anyone have any experience with this kind of thing or know if it would be appropriate at all? If so please provide some advice or point me in the right direction.
Thanks!
WCF is interoperable because it's accessed over HTTP. Visual Studio can help you build client libraries very quickly for WCF, but client access to WCF doesn't require anything other than HTTP calls with the proper payload. If you're looking at a remote server call and your built-in support in your embedded environment is basic HTTP, look at building your server-side as REST-formatted methods. Your debugger will thank you.
What kinds of data are you planning on transferring back and forth? For something this low level and proprietary I would recommend sticking with good old fashioned Sockets.
I will be passing configuration data back and forth...basically to enable technical support staff to remotely program the device. If I were using sockets this could be binary data, but there is a requirement that customers with firewalls shouldn't need to open any ports. Because of this I was thinking of sending XML over HTTP. So, is it better to use WCF or REST on the server side? Or WCF with REST?
I'm curious about your "customers with firewalls" requirement. Sockets with binary data or XML over HTTP can use any port (not just port 80), and I'm curious if your device will be "listening" on the network, or just making an outbound connection. If your device is listening, you will need to open a port on the firewall. Making an outbound connection ("phoning home") is much easier on the firewall.
So I think you could use sockets and binary data. However, I have faced similar issues on the last two projects, and I really wanted to implement WCF using REST on the embedded device, but no one else wanted to do it - I'm hoping someone else will be first, and publish some results!
Good Luck! (and post your results!)