You have a privilege to create a quiz (QnA) related to this subject and obtain creativity score...
By Ivan:
https://bitbucket.org/t-i-p/tip/wiki/TRM%20(Shipper-Receiver)%20Architecture
By Yair:
Licensed product
Demo version will work for us
http://www.lightstreamer.com/ls-features
compare to socketio to lightstreamer
http://blog.lightstreamer.com/2013/05/benchmarking-socketio-vs-lightstreamer.html
Licensed product – I did not see if there is a dev version
http://apigee.com/about/pricing/apigee-edge-pricing-features?int_content=menu
Communications with WebSockets The following article bottom image looks like our application
http://soa.sys-con.com/node/1315473
Comparisons of all the websockets servers
https://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations
Light streamer on list
There are other JAVA implementations that look interesting;
https://kaazing.com
https://www.pushtechnology.com
CAUTION
Was it clear so far?
https://samsaffron.com/archive/2015/12/29/websockets-caution-required
Load balancing
Lost packets
Queues
Jeff your comments are required from the Server perspective.
Ivan your comments are required from client perspective (how do deal with shipper’s fire wall)
https://cometd.org/about/
https://docs.cometd.org/current/reference/#_cometd_java_libraries_and_servlet_3_0 – can work with Tomcat and JBoss
Comments on communications:
By Ivan:
There are some valid concerns in that article, but most of them do not apply to us. Firstly, we are not using Ruby. Secondly, our WS connections are not originating from browsers, so on the TRM side there will only be as many connections per server as there are clients (which should be dozens at most). TRM-to-HUB is more relevant to that question, as there may eventually be hundreds or even thousands of deployments. And I agree that in most of these scenarios long-polling or even periodic synchronous requests might actually suffice. (Recall that I mentioned that early on when you started insisting on having the actual "push" functionality.) In either case, I am confident that we can scale our cloud appropriately and manage the load by a load balancer. The fact that we are not dealing with browsers also eliminates the need to support legacy software, which means that WS support per se is not a problem. Finally, like I said previously, there should be no changes to the shipper's firewall rules.
https://cometd.org/about/
CometD claims to be transport agnostic, in the sense that all we need to know is their API. Under the covers it will use the best transport available. I am guessing in the following order of precedence: WebSockets -> Comet -> HTTP.
----------------------------------------------------------------------------------------------------------------------------
Comments by Jeff:
Several frameworks, including CometD, allow to work with the regular Servlets(Jetty)/Tomcat/JBoss server side in HTTP or WebSockets.
We have several participants responsible for several components.
Some components are already "work in progress".
I suggest to keep components growing in functionality with the platform convenient to a developer.
We will connect later using one or more communication protocols and learning from each other.
I start hub with traditional and quick framework based on HTTP and focusing on building workable demo.
