mtahmed / antnest Goto Github PK

Right now, one needs to spin-check with sleep. This is not a good method. The system should be more event-based.

Find some way to avoid doing that. Maybe have a is_last_frag classmethod in message.Message which operates directly on the bytes object instead of constructing a Message object from the bytes first.

Instead of using the passed in isinuse argument to __init__, it is simply set to False every time in MessageTracker. This is incorrect.

Currently it's ambiguous and there might be caveats that are not easily decipherable from the code.

For example currently, only classes that have the init arguments "stored" in them as attributes are "properly" serialized and deserialized because those attributes are used for initialization. This should be documented somewhere.

TODO: We should allow not storing the init arguments and instead allow creating empty objects with attributes injected later. This would require e.g. having no mandatory arguments etc. or using some trickery to bypass init by call new directly etc. (NOT IDEAL!)

$ python commands/start_master.py
2013-11-16 05:56:17 MESSENGER: Receiver up!
2013-11-16 05:56:17 MESSENGER: Sender up!
^C
Traceback (most recent call last):
  File "commands/start_master.py", line 26, in <module>
    start_master()
  File "commands/start_master.py", line 18, in start_master
    this_node.worker()
  File "/home/mtahmed/repos/antnest/master.py", line 69, in worker
    time.sleep(2)
KeyboardInterrupt
^C
Exception KeyboardInterrupt: KeyboardInterrupt() in <module 'threading' from '/usr/lib/python3.3/threading.py'> ignored

Threads don't shutdown properly on ^C. A solution would be to implement a stop() method in the Node classes.

Right now there are a number of scripts like start_slave.py, start_master.py and so on. Merge them into one antnest script which does all of the actions above.

It could be used e.g. like this:

antnest start-slave -p 33311

OR

antnest create-job -j jobs/reverse_strings.py

I had the idea for this a long time ago but I was more focused on getting the system more architecturally sound before moving to other use-case "features".

This is (roughly) how it work work:

In Master:

messenger = Messenger()
messenger.add_hooks(Compress, Encrypt)

The hooks will be applied in that order ... first Compress and then Encrypt.

In Messenger:

def add_hooks(hooks):
    for hook in hooks:
        self.hooks.append(hook())

def send(msg):
    ...
    for hook in self.hooks:
        msg = hook.apply(msg)
    ...