Git Product home page Git Product logo

iams's Introduction

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.

iams's People

Contributors

wraithan avatar

Stargazers

avatar avatar

Watchers

avatar avatar avatar

iams's Issues

Neither side handles dropped connections.

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.

Look into superclass for abstracting common code.

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.

Neither side handles dropped connections.

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.

Limited size messages.

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.

Create wiki page for usage.

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.

Better error handling.

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.