We'd like you to write a small inter-application messaging system. Any language you prefer, and any operating system is OK, although open-source languages/OSs are preferred. It can be P2P or use a centralized server. Send us the code plus a short description of why you made the choices you did in designing this.
Here are the specifications:
-
It should work between hosts -- apps messaging each other don't have to be on the same system to send messages. It should be semi-trivial to port to another language or OS.
-
It should have some mechanism of at least attempting to guarantee delivery. Guaranteed delivery usually requires some special work, but for our purposes we'll drastically simplify it as follows: Queued messages don't have to survive failure of the sending system (or optionally the central server), and we'll assume that there will never be more than 65535 messages stuck in the delivery queue. You just have to make sure messages do not disappear into the ether if something's temporarily keeping the recipient app from accepting messages, and be able to resend such messages after some decent period.
- It can use other libraries and applications (a database, a caching system, files, web servers, &c.) to provide transfer, storage, hosting of the app itself, &c. -- you can use existing applications to do the grunt work. With one exception -- you can't use an existing messaging system (can't cheat by writing a couple of JMS classes in Java, or use RPC or some similar thing in an MS language).
- It will only send strings. This is because we're assuming that any modern language probably has serialization capabilities.
- XML can be used, as long as it's your own schema (not SOAP). You can use another format (which could save you from having to write a parser), or write your own protocol.
To give you a good idea of the size of this, we expect it will be 1-4 classes (if you use OOP), and about 75-300 lines of code, although under some circumstances it could be somewhat shorter or longer.
Why we chose this: We've written 3 or 4 of these for various purposes (one was for the new Dream Marriage chat system, and another was for P2P communication between multiple PHP applications). So we feel that we have a good idea of the pros and cons of a solution you come up with. It's something that enterprise programmers don't usually have to write, but which is kind of a fun problem that can have some unique solutions. We hope to see your solution soon.