How to connect one parent to multiple children?

[cxrodgers]

This is sort of a continuation of our discussion in #93 (comment)
But that title is not so relevant anymore.

The situation is that I am trying to connect one Parent Pi to multiple Child Pi. Currently, I can connect the Parent to one Child at a time, so I know the Children are each set up correctly. However, I am not sure how to tell the Parent to expect multiple children.

An important pref is likely CHILDID, which currently expects a string. Is the idea that it would expect a list for the case of multiple children? When I provide a list, this happens:

DEBUG:networking.station_02.Pilot_Station.Pilot_Station-3:FORWARDING (router): [b'rpi03', b'{"flags": {}, "timestamp": "2021-06-07T13:51:40.688037", "ttl": 5, "sender": "rpi01", "to": ["rpi02", "rpi03"], "key": "START", "value": {"child": {"parent": "rpi01", "subject": "testmouse_paft"}, "task_type": "PAFT Child", "subject": "testmouse_paft"}, "id": "rpi01_13"}']
ERROR:tornado.general:Uncaught exception in zmqstream callback
Traceback (most recent call last):
  File "/home/pi/.venv/autopilot/lib/python3.7/site-packages/zmq/eventloop/zmqstream.py", line 455, in _handle_events
    self._handle_send()
  File "/home/pi/.venv/autopilot/lib/python3.7/site-packages/zmq/eventloop/zmqstream.py", line 492, in _handle_send
    status = self.socket.send_multipart(msg, **kwargs)
  File "/home/pi/.venv/autopilot/lib/python3.7/site-packages/zmq/sugar/socket.py", line 555, in send_multipart
    return self.send(msg_parts[-1], flags, copy=copy, track=track)
IndexError: list index out of range

Alternatively, should the Children be serially connected, each a Child of the other? Can there be a multi-generational setup like this? If so, not sure if LINEAGE should be PARENT or CHILD.

I suppose alternatively, I could try to manually send the message to start the task to each child separately. This is how we send the message to one Child.

        self.node = Net_Node(id="T_{}".format(prefs.get('NAME')),
                             upstream=prefs.get('NAME'),
                             port=prefs.get('MSGPORT'),
                             listens={},
                             instance=False)

        self.subject = kwargs['subject']
        value = {
            'child': {
                'parent': prefs.get('NAME'), 'subject': kwargs['subject']},
            'task_type': self.CHILDREN['rpi03']['task_type'],
            'subject': kwargs['subject'],
        }

        # send to the station object with a 'CHILD' key
        self.node.send(to=prefs.get('NAME'), key='CHILD', value=value)

However, I'm not sure how to modify this last line to go to the correct child. It seems to just go to whichever one is specified in CHILDID. I tried the obvious thing (changing the to field to the child's name), but no message arrived, I'm not sure I was doing the to syntax correctly.

thanks!!

[cxrodgers]

might be an easy fix:
cxrodgers@18abff2

Would of course have to add a check for whether CHILDID is a list or not. Still testing...

[sneakers-the-rat]

Yes, related to the previous issue --

i think we should move away from hardcoded ips/ports/relationships towards a model where agents can be more flexibly deployed (eg. no fixed notion of 'child' and 'parent,' but communication between multiple agents is specified programmatically by the structure of the task), but before we have an automated means of discovery they still need to be parameterized somewhere.

The way I would imagine doing this for now would be to have a Net_Node instantiated by the Task which has the Pilot_Station as its upstream, and if the pilots intended to be the children had the first Pilot as their parent, then they should connect their Pilot_Station to the parent pilot's, and then messages addressed to the children from the node in the task should be routed correctly... from there you could START a task in which the children create their own nodes and connect back to the node in the task.

Alternatively you could create n nodes in the task and have them connect directly to the children to start the subtasks, which then spawn nodes to return communication.

So if that fix^^ works for you, then that (maybe with a little if: ... else: to handle strings as childids) seems like a very reasonable thing to incorporate in the package in the meantime :)