wraithan / iams Goto Github PK
View Code? Open in Web Editor NEWinter-application messaging system written as a test for a job.
inter-application messaging system written as a test for a job.
iams - Inter-Application Messaging System Written as a test for Partheon. Tracking my train of thought in this file for design. Initial design (before writting any code) is to use Python and use its socket functionality, using JSON for the serialization allowing for an ID to be sent along with the message. Going to have the recieving application send a message in acknowledgement and verify that a message is only acted on if the ID has timed out. Going to use a standard queue for storing messages until they are acknowledged as recieved. Test does not specify whether the app can/should be multithreaded, considering using stackless to allow for using channels to communication between the coroutines which would make recieving messages a lot more certain. That or just have the messaging object checked on as part of a event loop style. Initial handshake will send the location where messages can be sent to the specific applicaition. Two example apps: 1. application that send anything written on stdin to the server specified on the commandline and writes anything recieved to stdout. 2. server that responds to properly formed requests with the requested data, and says something to the client application if the request is malformed. Objects: ChrisIPCClient -- An object that uses JSON to serialize objects and sends them to the socket specified at objection creation. ChrisIPCServer -- An object that binds to an address or unix socket location. Uses JSON deserialize recieved objects and adds them to a queue. ChrisIPCClient's send method will have a way of indicating that it expects a message back, if it expects a message back, it will ignore the first ack and wait for a message with content with the same ID. This allows the server to not have to worry about acks and be able to send the data again if it is requested again, allowing the client to be the only one that worries about acks.
Current: No error handling other than timeout.
Problem: Currently any little error in the json en/decoding or sockets is catastrophic.
Solution: Add error handling around the json calls and socket calls, should all be centralized around client.send client.update server.update server.reply.
Current: There is no code to detect or react to a dropped/lost connection.
Problem: Due to this the application will try to read or write to the dead connection likely giving errors and or silently failing and sending out into the ether.
Solution: the code needs to detect when a connection is lost and reestablish it if at all possible. Also the client should send it's socket Id in a handshake like manner so that the server can place it in the right place and resume sending replies to it.
Current: There is no code to detect or react to a dropped/lost connection.
Problem: Due to this the application will try to read or write to the dead connection likely giving errors and or silently failing and sending out into the ether.
Solution: the code needs to detect when a connection is lost and reestablish it if at all possible. Also the client should send it's socket Id in a handshake like manner so that the server can place it in the right place and resume sending replies to it.
Current: Messages are limited to 4096 minus the message id length, and reply expectance, and json markup.
Problem: Messages that are too long will push the message ID and reply expectance off, along with some of the message.
Solution: have send split the message up into acceptable chunks and add a flag for how many chuck and what chunk is currently being sent.
Current: There is duplicate code in both server and client that is very similar.
Problem: This is similar to copy/paste problems in that a code fix in one place need to be applied in another place.
Solution: abstract as much of the send/reply and update/update code as possible to make it so common functions handle them. Also handle the searching of message/reply queues.
Current: No wiki page.
Problem: No documentation other than docstrings on how to use the code.
Solution: extract the doc strings in order to start the documentation, then round out with extra comments.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.