Ahh! I would suggest you think about the flow of your application this way which might clear things up:
- User on website loads a page, something like /changeImage.html?newImage=picture1.jpg
- nodejs server receives request for /changeImage.html and parses the GET string to find the var newImage = "picture1.jpg"
- Before returning to the user (rendering the HTML response for changeImage.html), your server (not your html) runs a method to pass the TCP command to your sign ( sendSignMessage({image = picture1.jpg}, callback) ). sendSignMessage would connect to the digital sign (or make use of a previously initialized connection) per [[ http://nodejs.org/api/net.html#net_net_connect_arguments ]]
- sendSignMessage() waits until it receives a response from the sign and passes that message on to the callback passed to it, which in turn should finally render out (with that response included) to the user on the website.
There are a few reasons for this type of architecture:
- While I haven't done much work with digital signs, I have interfaced with a lot of lighting control hardware, and those devices have trouble dealing with lots of connections. Having your server maintain one connection which is a proxy for all of your web users is useful
- It's really hard (and often times impossible) to get javascript in the browser to connect to arbitrary ports
- It's also really hard (even with websocckets) to have javascript in the browser act as a raw TCP connection to send arbitrary messages to a server that isn't the same as the webserver (cross domain problems)
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en