Skip to main content

json messaging (2/2)

Took a good 2 hours to change all the messages into JSON format and make it work.

But it is done. All is JSON.

Using it like a map, currently with three key-value pairs:

"id" : for entering a session ID of another session if needed. Currently used for the web client to receive a acknowledge response to confirm that the target received the message (mainly for testing purposes).

"type" : probably the most functional data going through all this. Current types are
STARTUP_TYPE - for when the target sends its initial message, the server uses this to mark which session is the target.
REQUEST_TYPE - for when the web client sends a request to the target. Server uses this to send request to target.
ACK_TYPE - for when the target finishes carrying out the requests and sends an acknowledgement of the completion of the request to the server. Server uses this to send confirmation to the web client 
MISC_MSG_TYPE - for anything else.
DEBUG_TYPE - currently for the pinging that the Raspberry Pi is sending to the server. 

"message" : currently holds messages that are visible in the web client's screen. As the screen would most likely be gone in the end, this and MISC_MSG_TYPE might disappear. 

Anyways, code got cleaner once every message was converted to JSON (no more regex blobs), but it's still messy in some parts.
Labels:

Comments

Post a Comment

Popular posts from this blog

dabbling with cylon

I'm playing around with Cylon JS whenever I have the time. in order to use the leap motion for control, the hand control will need to communicate with the pc that is connected to the leap motion device (leap motion does not provide an arm/linux driver). it seems that Cylon devices can communicate with each other through socket.io or http, and I am currently playing around with that.
Post a Comment
Read more

nodejs migration

Having been playing around with NodeJS recently,  I (naturally?) started re-writing some of the OpenSesame code using Node last night. I think I've only worked on it around 2 hours so far, but I've already set up a basic client interface (a socket.io chat tutorial rip) with a server that the Raspberry Pi can connect to and receive requests to open the door.  This is probably due to socket.io's socket management (socket.io is the WebSocket module for Node); for my first implementation, I had to manually write up a structure that managed sockets, but that is pretty much handled by socket.io. Also, the servo control logic is pretty much recycled (and the Raspberry Pi code is still Python), and I do remember spending some good time figuring that out.  Cool neverthelss. I'll probably keep both versions around.
Post a Comment
Read more

websockets and mobile networks and ssl

Gahhh. Just going to ramble on this one: Websockets is unstable going through cellular networks Searched Google and solution seems to be SSL connections Tried to implement, and it works to some extent,  but realized that I'll have to have both Apache, which was running my web front end, and Tornado both listen to 443 which cannot happen Realize finally that Tornado is a SERVER just like Apache Try to implement web client through Tornado It works but Websocket server and the web client still different instances so still can't have both listen, or that's what I'm thinking but I don't have time to think about it at present. Gotta sleep.
Post a Comment
Read more