We develop system with client-server architecture. But in our case client must communicate with server in off-line file mode. Is it correct to use AMQP in this case?
Yes you can do that in some cases. I suggest that you email the rabbitmq-discuss list (you need to subscribe first). That's a good place to ask questions of this sort!
Hope this helps.
alexis
RabbitMQ
Related
I have to implement a dsniff version for bro as my final year project. So I started by writing bro scripts where I use protocol events that were implemented by Bro. The thing is Bro didn't implement events for all the protocols and LDAP is one of protocol that suffer from absence of events in BRO. So I was wondering what is the best way to achieve this. I mean : Do I need to add dissectors and events for theses protocols, or do I need to use some functionality of that I missed? (I'm newbie in Bro)
Thank you very much for your help.
For others that want to do the same as me, there's no analyser implemented for ldap. But this not a big problem because there's a handfull tool that helps us to write, simply and easily, analysers of protocols that uses Tcp or UDP as transport layed. This tools is called Binpac. Here's a link of a quickstart up: https://www.youtube.com/watch?v=1eDIl9y6ZnM.
And for people who wanted to know what we have managed to do for the project Bro-Dsniff, here's the link of git : https://github.com/rsabir/bro-dsniff
I am trying to develop a publish/subscribe system.
To this end, I have read some papers and articles regarding it.
And they all talk about Messaging service as an integral part of publish/subscribe system.
My question is, can I develop a publish subscribe system without using MOM like JMS?
Or am I missing or oversimplifying things?
I do not think you are oversimplifying things. There are stand-alone products available that provide advanced functionality based on publish/subscribe, without being part of a larger MOM system.
One of them is a group of products implementing the Data Distribution Service (DDS) specification, as standardized by the Object Management Group (OMG). Check out this Wikipedia entry for a very brief introduction and list of references.
DDS supports many advanced data management features like a strong-typed and content aware databus, distributed state management and historical data access. Its rich set of Quality of Service settings allows to off-load a lot of the complexity from your applications to the middleware. This is all based on the publish/subscribe paradigm.
If you would tell more about your application, then I might be able to point you to similar use cases using this technology -- if you are interested.
It depends what you mean by "MOM". If you think MOM = JMS then yes, there are plenty of pub/sub applications which are not JMS servers (off the top of my head): 0MQ, TIBCO Rendezvous and the many AMQP implementations around.
I guess my definition of MOM is an infrastructure for reliably getting a message from one system to another in an asynchronous manner. Pub/sub is a feature on top of the message transport which allows a message to be distributed to multiple other systems. Once you get beyond the point of opening a socket and stuffing a bunch of bytes down it, I would argue you are in the realm of MOM.
So, no you don't need JMS to do pub/sub....there are plenty of open-source and closed-source alternatives out there. Which one depends on your requirements and skills.
You can look at multicast that provides one to many communication. Multicast does not require MOM, instead it requires multicast enabled IP network. Usually the network routers take care of creating copies of message and delivering messages to destinations.
I am going to write a client/server card game for learning/practice purposes, and intend to use Java for both the client and server to begin with. In the future I will be looking to continue to use this project for learning, and thus will want write additional clients in other languages such as C and C++.
The main detail I am unsure about is whether I need to use a MOM with a message broker, or if I can get away without using one.
My initial thought was I could handle the failure to send/receive a message on both sides, prompting an attempt to re-send the message resulting into the game being ended if the amount of attempts reaches a maximum.
However, instead of just having the game client and game server I was thinking about having a client, lobby server and game server. This way I would need the message broker to route the correct messages to the correct server, however I am unsure whether apart from that if I have any need for message broker, as I'm not sure if I really need to have any facility for message persistency.
I am leaning towards going for a MOM with a message broker, but I would welcome anymore lightweight solutions if I am doing so unnecessarilly. That said, if I did what would be a suitable cross-language MOM to use? I have seen quite a few suggested on SO before, but I'm not sure what would best meet my needs.
For cross language MOM - I suggest you use Apache ActiveMQ. It complies to the JMS spec and also has a robust C++ client library. It is open source (Apache license)
Yes the other lightweight option you could explore is HTTP. esp. for the client to server communication. (Since clients may need to connect to the server across firewalls etc - HTTP port is easiest to access etc).
For lobby server - game server communication - I like your idea of MOM.
Could you give some examples of zeromq?
Let's say you want to have a bulletin board of some kind. You want to allow only some people to see it, by subscribing to the bulleting board.
This can be done using the publisher/subscriber model of ZeroMQ.
Now, let's say you need to send some asynchronous messages. That is, when a message is sent from system A and needs to get to system B, it is guaranteed to be delivered later, even if systems A and B cannot communicate at the moment when that message is sent. You can imagine a use case being SMS messages.
This can be done using asynchronous messaging model of ZeroMQ.
Basically, any JMS compliant solution like ZeroMQ will allow you to reliably broadcast or send a "message", whatever that message may be, to some other party with as little hassle as possible.
Please see the ZeroMQ blog -- they regularly post usage stories about different deployments, language bindings, etc.
IPython uses ZeroMQ for parallel computing features, the qt console and the notebook.
Last time Rick Olson created a "clone" of Dropbox: https://gist.github.com/122849a52c5b33c5d890
My personal use of this library is cross language communication:
I pass data between Python and Haskell
They also have an excellent guide that offers a complete peek into the possible use cases and their real time applications.
And if you have more time, you can go thru the whole website
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.