search

assisi / playground

Extensions to the Enki simulator for the ASSISI|bf project.
Other
2 stars 3 forks source link

Add return status to key simulator/client interactions #54

Open rmm-fcul opened 8 years ago

rmm-fcul commented 8 years ago

When spawning a bee / CASU / wall, the request is sent and the client immediately moves on to the next line of code. But no confirmation is provided, leaving the client in the dark about whether it actually had any effect. Perhaps a) there was an error in the command (e.g. attempted to spawn outside of the arena/world); b) there was a repeated request for spawn same object; c) there wasn't a simulator running!

The simulator instance provides a text output for b) but nothing appears to come back to the client.

Confirmation of object removal (issue #20) should fall under the same enhancement.

In a similar way, when attaching behavioural handler client, we obtain a connection, and the client receives the feedback that the command succeeded (i.e. it is blocking until it succeeds). But some additional information could be provided, including the simulation speed, so that the client can scale its behavioural program accordingly.

[Please comment if you think this should be two issues rather than one]

dmiklic commented 8 years ago

This will probably require changing the communication type from pub-sub to req-rep for some simulator API calls. It's doable, but I'm a bit concerned about making a mess of what's quite a clean communication interface at the moment. I'll take a look.

rmm-fcul commented 8 years ago

Would it be possible to retain the cleanliness by wrapping up a pair of interactions to mimic request/reply behaviour? e.g., 

def spawn_with_ack(objname, **kwargs):
    self.spawn(objname, **kwargs)
    return self.is_present(objname)

or would implementing the is_present() query already require this change?

dmiklic commented 8 years ago

Yes, ìs_present` already requires changes in the underlying communication protocol (at ZMQ level), which is something I'm weary of, but I'll look into it.

rmm-fcul commented 8 years ago

ok, another possible idea would be to publish a list of all objects in the server. Then the spawn and remove/kill methods could query their local copies of this list. It doesn't cover all the client/server interactions but if it is possible without deviating the comms type it would still be useful.

Anyway, I'll leave it to you to investigate possibilities.

plsm commented 8 years ago

The ZMQ documentation has examples on how to build a request/reply application. I think this solution could be also applied to issue #73 .