We're starting development of the new game project using Ruby. We decided to use one of the asynchronous Ruby servers, but we cannot decide which one to choose. Options are:
Goliath
Cramp + thin/rainbows
rack-fiber_pool + rack + thin/rainbows
eventmachine_httpserver
All of them seem to be working with HTTP requests. Cramp also supports Websockets and Server-Side events from the box.
Do you know any pros & cons of these servers?
I've used eventmachine_httpserver to expose a RESTful API in an EventMachine-based IRC bot and would definitely not recommend it for anything serious. It seems more like a minimal proof-of-concept than a serious web server, perhaps best illustrated by the parse_headers hack I had to use.
You may also want to look pub/sub services like nats.
Related
I am trying to see if I can create a simple website, like a blog, using only Ruby. No Rails or a database or outside web servers. I plan to store the data in a file for persistence.
I wanted to use TCPServer, CGI, and Net::HTTP.
Is there an easier way I can use?
There are a lot of moving parts when designing a website.
Depending on the purpose of the exercise, you might want to consider using a very simple web framework like Camping, Sinatra, or Ramaze. This is probably the best solution if you're trying to get a top level understanding of web programming because it only has exactly what you need (Camping is less than 4k!) and handles stuff like routing.
Building a web server is more an exercise in HTTP parsing. You might want to omit the framework and try to build something on top of Rake (an API for lots of popular web servers) and a simple web server like Webrick or Thin.
You could also try Espresso
It is easy to learn and fast to run.
And offers all the liberty you need for creation process.
Also it has no hidden "fees", everything is transparent.
Well, I have doubts about this technology, more precisely in its implementation, can not find good examples on the Internet, as it involves javascript and php, only, you would have some links where I can find this stuff really works and that ?
A great source for all things Comet is Comet Daily. Unfortunately it's not updated all that often any more but there are some fantastic old articles in there. It's contributed to by guys that have been developing Comet solutions for over 10 years.
Comet seems to get incorrectly bundled as meaning just one particular connection mechanism is used, but it's actually a paradigm for realtime push from server to client. Comet servers can use HTTP Streaming, HTTP Long-Polling, classic polling and WebSockets.
If you are interested in the latest Push Technology then you should take a look at WebSockets which is a standardised approach to not only server to client push, but also bi-directional realtime communication between servers and clients (web browsers and other clients).
Some current trending push technologies are:
socket.io
Hosted WebSockets services such as Pusher - who I work for
Faye for self hosted Ruby or Node dev
SignalR for IIS and .NET
There are many more and more information on realtime web technologies can be found on this guide.
If you want to use PHP you could struggle to build an application using realtime Push which will scale above a small number of connections. Have a read through this question on concurrency - How to implement event listening in PHP for more information.
Do you specifically mean Ajax push? Because a more common method is comet push, I has been a while I worked with this, probably more browsers support this.
A good implementation can be found here:
http://www.ape-project.org/
Well it's called Ajax Push engine, so I suppose that is what you are looking for.
If you work with Java/Scala/Ruby/Groovy, take a look at Atmosphere, which is being actively developed/used (I'm the creator). There are many samples available.
Check out the Bayeux Protocol and CometD implementation in Java & Javascript.
From http://cometd.org/ :
CometD is a scalable HTTP-based event routing bus that uses a Ajax Push technology pattern known as Comet.
Here the link to an interesting article describing the technologies involved and a comparison of CometD and Atmosphere implementations.
Socket.IO seems to be the most popular and active WebSocket emulation library. Juggernaut uses it to create a complete pub/sub system.
Faye is also popular and active, and has its own javascript library, making its complete functionality comparable to Juggernaut. Juggernaut uses node for its server, and Faye can use either node or rack. Juggernaut uses Redis for persistence (correction: it uses Redis for pub/sub), and Faye only keeps state in memory.
Is everything above accurate?
Faye says it implements Bayeux -- i think Juggernaut does not do this -- is that because Juggernaut is lower level (IE, I can implement Bayeux using Juggernaut)
Could Faye switch to using the Socket.IO browser javascript library if it wanted to? Or do their javascript libraries do fundamentally different things?
Are there any other architectural/design/philosophy differences between the projects?
Disclosure: I am the author of Faye.
Regarding Faye, everything you've said is true.
Faye implements most of Bayeux, the only thing missing right now is service channels, which I've yet to be convinced of the usefulness of. In particular Faye is designed to be compatible with the CometD reference implementation of Bayeux, which has a large bearing on the following.
Conceptually, yes: Faye could use Socket.IO. In practise, there are some barriers to this:
I've no idea what kind of server-side support Socket.IO requires, and the requirement that the Faye client (there are server-side clients in Node and Ruby, remember) be able to talk to any Bayeux server (and the Faye server to any Bayeux client) may be deal-breaker.
Bayeux has specific requirements that servers and clients support certain transport types, and says how to negotiate which one to use. It also specifies how they are used, for example how the Content-Type of an XHR request affects how its content is interpreted.
For some types of error handling I need direct access to the transport, for example resending messages when a client reconnects after a Node WebSocket dies.
Please correct me if I've got any of this wrong - this is based on a cursory scan of the Socket.IO documentation.
Faye is just pub/sub, it's just based on a slightly more complex protocol and has a lot of niceties built in:
Server- and client-side extensions
Wildcard pattern-matching on channel routes
Automatic reconnection, e.g. when WebSockets die or the server goes offline
The client works in all browsers, on phones, and server-side on Node and Ruby
Faye probably looks a lot more complex compared to Juggernaut because Juggernaut delegates more, e.g. it delegates transport negotiation to Socket.IO and message routing to Redis. These are both fine decisions, but my decision to use Bayeux means I have to do more work myself.
As for design philosophy, Faye's overriding goal is that it should work everywhere the Web is available and should be absolutely trivial to get going with. I'ts really simple to get started with but its extensibility means it can be customized in quite powerful ways, for example you can turn it into a server-to-client push service (i.e. stop arbitrary clients pushing to it) by adding authentication extensions.
There is also work underway to make it more flexible on the server side. I'm looking at adding clustering support, and making the core pub-sub engine pluggable so you could use Faye as a stateless web frontend for another pub-sub system like Redis or AMQP.
I hope this has been helpful.
AFAIK, yes, apart from the fact Juggernaut only uses Redis for Pubsub, not persistence. Also means client libraries in most languages have already been written (since it just needs a Redis adapter).
Juggernaut doesn't implement Bayeux, but rather has a very simple custom JSON protocol
I don't know, but probably
Juggernaut is very simple, and designed to be that way. Although I haven't used Faye, from the docs it looks like it has a lot more features than just PubSub. Being built on top of Socket.IO has it advantages too, Juggernaut's supported in practically every browser, both desktop and mobile.
I'll be really interested in what Faye's author has to say. As I say, I haven't used it and it would be great to know how it compares to Juggernaut. It's probably the case of using the best tool for the job. If it's pubsub you need, Juggernaut does that very well.
Faye certainly could.
Another example of a similar project on top of Socket.IO:
https://github.com/aaronblohowiak/Push-It
EDIT: I forgot to include the prime candidate for web applications: JSON over HTTP/REST + Comet. It combines the best features of the others (below)
Persevere basically bundles everything I need in a server
The focus for Java and such is definitely on Comet servers, but it can't be too hard to use/write a client.
I'm embarking on an application with a server holding data, and clients executing operations which would affect this data, and thus require some sort of notification across all interested/subscribed clients.
The first client will probably be written in WPF, but we'll probably need to add clients written in other languages, e.g. a Java (Swing?) client, and possibly, a web client.
The actual question(s): What protocol should I use to implement this? How easy would it be to integrate with JS, Java and .NET (precisely, C#) clients?
I could use several interfaces/protocols, but it'd be easier overall to use one that is interoperable. Given that interoperability is important, I have researched a few options:
JSON-RPC
lightweight
supports notifications
The only .NET lib I could find, Jayrock doesn't support notifications
works well with JS
also true of XML-based stuff (and possibly, even binary protocols) BUT this would probably be more efficient, thanks to native support
Protobuf/Thrift
IDL makes it easy to spit out model classes in each language
doesn't seem to support notifications
Thrift comes with RPC out of the box, but protobufs don't
not sure about JS
XML-RPC
simple enough, but doesn't support notifications
SOAP: I'm not even sure about this one; I haven't grokked this yet.
seems rather complex
Message Queues/PubSub approach: Not strictly a protocol, but might be fitting
I hardly know anything about them, and got lost amongst the buzzwords`-- JMS? **MQ?
Perhaps combined with some RPC mechanism above, although that might not be strictly necessary, and possibly, overkill.
Other options are, of course, welcome.
I am partial to the pub/sub design you've suggested. I'd take a look at ZeroMQ. It has bindings to C#, Java, and many other platforms.
Bindings list: http://www.zeromq.org/bindings:clr
I also found this conversation on the ZeroMQ dev listing that may answer some questions you have about multiple clients and ZeroMQ: http://lists.zeromq.org/pipermail/zeromq-dev/2010-February/002146.html
As XMPP was mentioned, SIP has a similar functionality. This might be more accessible for you.
We use Servoy for this. It does automatic data broadcasting to web-clients and java-clients. I'm not sure if broadcasts can be sent to other platforms, you might be able to find an answer to that on their forum.
If you want to easily publish events to clients across networks, you may wish to look at a the XMPP standard. (Used by, amongst other things, Jabber and Google Talk.)
See the extension for publish-subscribe functionality.
There are a number of libraries in different languages including C#, Java and Javascript.
You can use SOAP over HTTP to modify the data on the server and SOAP over SMTP to notify the subscribed clients.
OR
The server doesn't know anything about the subscription and the clients call the server by timeout to track updates they are interested in, using XML-RPC, SOAP (generated using WSDL), or simply HTTP GET if there is no need to pass back complex data on tracking.
What is the best way to push data from a server written in Sinatra to a client? Think similarly to a chat room, but without Ajax polling every 2500ms.
I know of Juggernaut in Rails, but was curious about Sinatra.
A little googling turned up this blog post by Marc-André Cournoyer, which discusses the asynchronous response feature of the Thin web server and includes a link to an async-sinatra library to do just this. You could also take a look at orbited-ruby, a Ruby implementation of the Orbited Comet server. Both of these appear to be pretty new and untested, so you might have to do a little hacking yourselves to get things working correctly for your application.