What's a good realtime messaging protocol/server

Remote Side:There's a VISCA-Controllable Camera, connected to a PC (windows)I know there are VISCA-protocol libraries available to control the cameraIdeally the PC should be able to run a client, connect to a central server and accept commands to control the camera.

Near-side:Another PC, with access to the camera's video feed.A software client that can connect to the central server, and issue commands to the camera.

I'm thinking a Jabber/XMPP server, so I don't have to develop a server, no need to design a protocol, plus firewall issues are mostly solved. Then, develop a slave-client that receives instructions and talks to the camera via VISCA, plus another master-client that can read a joystick, and send appropriate commands.

My concern with XMPP is that it might not be real-time enough, there might be some lag. Any other alternatives/architecture I should look at?

My concern with XMPP is that it might not be real-time enough, there might be some lag.

I seriously doubt you can escape this, especially considering that it's not going through a local network. No matter what protocol you use/develop you'd still have lag depending on the congestion of the route your packages take.

You are only concerned with the command aspect, not streaming video through the central server, right?

For something relatively simple, try to look at one of those alread-built integration framework like Apache Camel / Spring Integration, and use ZeroMQ for a relative easy to use messaging library. If design your message spec properly, this shouldn't be too hard to pull off.

My concern with XMPP is that it might not be real-time enough, there might be some lag.

I seriously doubt you can escape this, especially considering that it's not going through a local network. No matter what protocol you use/develop you'd still have lag depending on the congestion of the route your packages take.

Yeah, the network lag I can live with. I don't know enough about jabber/xmpp, but if it's like typical instant messenger apps, sometimes messages don't come instantaneously.

Quote:

You are only concerned with the command aspect, not streaming video through the central server, right?

Yes, streaming video is done with a video conferencing app. But that app doesn't know about camera PTZ control.

Quote:

For something relatively simple, try to look at one of those alread-built integration framework like Apache Camel / Spring Integration, and use ZeroMQ for a relative easy to use messaging library. If design your message spec properly, this shouldn't be too hard to pull off.

The problem with XMPP is not latency, but rather the insane complexity of the protocol. I would never choose it for an application like this, but if you're already sold, I guess strophe is a good place to start.

You know, thinking more about this, why not go with IRC considering the things you're transmitting aren't that complex? That way the only thing you'd need to write is a client which interprets the messages (and even then you wouldn't necessarily have to deal with IRC but could instead use a regular client and have your app parse the logs).

What language are you going to do this in? That should influence the decision first. The only library I could find quickly was written in C. As such, I would recommend Python and a messaging server such as ZeroMQ or RabbitMQ. XMPP is a possibility, but I'm not sure it's really what you want.

What language are you going to do this in? That should influence the decision first. The only library I could find quickly was written in C. As such, I would recommend Python and a messaging server such as ZeroMQ or RabbitMQ. XMPP is a possibility, but I'm not sure it's really what you want.

Umm, he still has to design a protocol even if he uses XMPP, as it doesn't have built it in commands for PTZ camera control. XMPP just functions as a transport/session protocol in this case. Writing an application protocol is going to be necessary no matter the underlying protocols. Whether writing that protocol will be easier on top of XMPP or ZeroMQ or raw sockets isn't a question we can answer with the information we have.

Likewise, having an XMPP server or message broker in the middle doesn't ipso facto remove the need for development of a "server" application. It's not even apparent a central server is necessary. But even if a central server is a requirement, it's quite possible neither XMPP or any message broker will be enough to meet his needs. Again, there's no way to determine the best solution based on the information we have.

Something somewhere has to listen to the commands, and pass those onto the underlying camera control API. Since this has to happen having it happen within the same process seems simplest, as such any sort of messaging API that lets you simply get going as fast as possible with the minim effort seems simplest. ZeroMQ is certainly simple enough for this, but well tested and broadly supported.

The only reason to go to something more complex (with the associated hassles to your just getting it going) is if it solves some problem you would otherwise have to then solve yourself.All I can think of that would be likely to affect the OP is whether or not this hass to pass unmolested through firewalls or be discoverable to the clients by something more flexible than a DNS lookup or not. If so that sort of information is critical to the discussion so should just be addressed directly rather than speculating.

The Camera host/client could be implemented in whatever connects to the camera easiest, while the "control" client could be a simple web page to push commands into the node-js server.

Having the camera client initiating the connection to the server over HTTP/HTTPS will ensure that you have as few firewall related issues as possible. The actual node-js server could be hosted anywhere that can be reached by the camera client and the user with a web browser.

The camera protocol would be a subset of the VISCA protocol, mostly the part that deals with PTZ control. I think I've found visca libs in both C and Java.

Having a server is not a hard-requirement. Ideally i'd like the remote-camera side to be as zero-conf as possible, if there was a server address, I could point it there and it can say "hey, camera's here", and the controller can just go and pick a camera. Which is why I first thought of IM-style applications. In my understanding, a server usually acts as go between for those, at least for session-initiation, and sometimes for the whole sessions.

I'd like something really simple, so I don't need to mess with the lower-level protocol, I just need a simple light-weight transport, with the added dumb-setup factor on the other side. It's just that XMPP is the one I've heard of, and I don't know what else is available.

Firewalls will definitely be an issue on both sides of the connection. The controller-app, and the controllee-app would be behind NAT/firewalls.

ZeroMQ seems interesting, but cursory reading doesn't tell me how I can connect from one end to the other (yet).I'll also look into Strophe and IRC (if only to make it feel like a botnet, with real bot-eyes).

How many cameras are we talking about? Is there a need for centralized command and control? Authentication?

Quote:

Ideally i'd like the remote-camera side to be as zero-conf as possible, if there was a server address, I could point it there and it can say "hey, camera's here", and the controller can just go and pick a camera. Which is why I first thought of IM-style applications. In my understanding, a server usually acts as go between for those, at least for session-initiation, and sometimes for the whole sessions.

Yes, typically the whole session will go through the server except for some operations like file transfer (even then, not necessarily). But that's also the easy part.

The hard parts are things you have to handle anyway: like discovery of what cameras are available, which isn't standardized in XMPP. Obviously, the simplest solution here is to just have them join a special group chat, but you still have to make those decisions and code them up. Likewise, you'll have to decide how to register accounts, and handle how to determine who can control which cameras (if you care).

Quote:

Firewalls will definitely be an issue on both sides of the connection. The controller-app, and the controllee-app would be behind NAT/firewalls.

Do you have control of them?

Quote:

ZeroMQ seems interesting, but cursory reading doesn't tell me how I can connect from one end to the other (yet).

Use zeromq_bind to receive incoming connections, and zeromq_connect to make them.

How many cameras are we talking about? Is there a need for centralized command and control? Authentication?

At this point, 1 camera, but I'm not limiting it to just 1. The controller will add the camera-IDs to his "buddy list", and "chat" with one camera at a time (not broadcast).

LordHunter317 wrote:

Quote:

Ideally i'd like the remote-camera side to be as zero-conf as possible, if there was a server address, I could point it there and it can say "hey, camera's here", and the controller can just go and pick a camera. Which is why I first thought of IM-style applications. In my understanding, a server usually acts as go between for those, at least for session-initiation, and sometimes for the whole sessions.

Yes, typically the whole session will go through the server except for some operations like file transfer (even then, not necessarily). But that's also the easy part.

The hard parts are things you have to handle anyway: like discovery of what cameras are available, which isn't standardized in XMPP. Obviously, the simplest solution here is to just have them join a special group chat, but you still have to make those decisions and code them up. Likewise, you'll have to decide how to register accounts, and handle how to determine who can control which cameras (if you care).

Having no experience with XMPP, I don't know yet how much of the functionality (such as presence, buddy list, etc) is already built-in. I'm imagining a library that lets me create a chat-bot, but will let me pass "pan-left 5 degress" messages on top of the underlying protocol.

LordHunter317 wrote:

Quote:

Firewalls will definitely be an issue on both sides of the connection. The controller-app, and the controllee-app would be behind NAT/firewalls.

Do you have control of them?

Quote:

ZeroMQ seems interesting, but cursory reading doesn't tell me how I can connect from one end to the other (yet).

Use zeromq_bind to receive incoming connections, and zeromq_connect to make them.

Having no experience with XMPP, I don't know yet how much of the functionality (such as presence, buddy list, etc) is already built-in.

It honestly depends on which client library you use. Such functionality is built into the XMPP protocol. However, some client libraries understand those concepts and provide high-level APIs to leverage them, while others essentially just let you pass arbitrary messages that XMPP servers will understand. For the latter, you have to implement the higher-level concepts (buddy lists, etc.) on top of the low-level API.

I can't help you on which libraries are which.

Quote:

LordHunter317 wrote:

Quote:

Firewalls will definitely be an issue on both sides of the connection. The controller-app, and the controllee-app would be behind NAT/firewalls.

Do you have control of them?

Quote:

ZeroMQ seems interesting, but cursory reading doesn't tell me how I can connect from one end to the other (yet).

Use zeromq_bind to receive incoming connections, and zeromq_connect to make them.

I decided on writing the thing in Python, chiefly because I already know it and because of relatively simple libraries for XMPP (SleekXMPP) and serial port i/o (PySerial). I started by using Java + Smack, but I realized there aren't any java libs for the visca protocol.

The only available visca lib that I found is in C, and C# both of which I can read, but not write.

The visca protocol itself is fairly simple, and I'm looking at libvisca for guidance. My PyVisca lib is not a direct port, I only need a specific subset of commands now.

XMPP works great, and allows minimal futzing on either side of the endpoint, just needs to know the jabberid of the camera you need to control.

The visca protocol itself is fairly simple, and I'm looking at libvisca for guidance. My PyVisca lib is not a direct port, I only need a specific subset of commands now.

Umm, why not use libvisca from python? The python ctypes FFI thingy may not be perfect, but it gets the job done. If you need arrays, there's numpy.ctypeslib which is quite nifty as well.

Writing the bare-bones py implementation is easier for me, than to figure out how to interface with the C libraries, given that I have little experience with C. It's something to look at when I need a more extensive implementation, and when I have a lot more time.