Our current way of dealing with handshakes is a quite questionable setup of a global broadcast for each packet. This is most likely also (by far) our biggest bottleneck and puts a massive burden on every single agent.
While this is fine in cases where it does make sense (the auction itself), once a agent wants to initiate a handshake it should have some kind of "private" topic it subscribes. e.g. instead of the current flow of:
- Broadcast Request
foo/bar/requests and everyone listens to everything coming in
- Global Auction at
foo/bar/auction and everyone listens to everything coming in
- Accept one Offer at
foo/bar/accept and everyone listens to everything coming in
- Ack Offer Accept at
foo/bar/ack and everyone listens to everything coming in
It should more closely resemble this:
- Broadcast Request at
foo/bar/request sharing a unique ID for the next steps, e.g. ABCDE
- Global Auction at
foo/bar/auction/ABCDE, agents that joined subscribe to foo/bar/accept/ABCDE
- Accept one offer at
foo/bar/accept/ABCDE, subscribe to foo/bar/ack/ABCDE
- Ack offer accept at
foo/bar/ack/ABCDE
One big personal recommendation for this would be to abstract the general topic handling. E.g. implement a proper dispatcher/broker pattern to pin topics to functions. Any other way solution would most likely sound easier at first compared to the amount of boilerplate work that this would require but add a massive amount of unexpected work when refactoring every single agent that we currently have.
Our current way of dealing with handshakes is a quite questionable setup of a global broadcast for each packet. This is most likely also (by far) our biggest bottleneck and puts a massive burden on every single agent.
While this is fine in cases where it does make sense (the auction itself), once a agent wants to initiate a handshake it should have some kind of "private" topic it subscribes. e.g. instead of the current flow of:
1. Broadcast Request `foo/bar/requests` and everyone listens to everything coming in
2. Global Auction at `foo/bar/auction` and everyone listens to everything coming in
3. Accept one Offer at `foo/bar/accept` and everyone listens to everything coming in
4. Ack Offer Accept at `foo/bar/ack` and everyone listens to everything coming in
It should more closely resemble this:
1. Broadcast Request at `foo/bar/request` sharing a unique ID for the next steps, e.g. `ABCDE`
2. Global Auction at `foo/bar/auction/ABCDE`, agents that joined subscribe to `foo/bar/accept/ABCDE`
3. Accept one offer at `foo/bar/accept/ABCDE`, subscribe to `foo/bar/ack/ABCDE`
4. Ack offer accept at `foo/bar/ack/ABCDE`
One big personal recommendation for this would be to abstract the general topic handling. E.g. implement a proper dispatcher/broker pattern to pin topics to functions. Any other way solution would most likely sound easier at first compared to the amount of boilerplate work that this would require but add a massive amount of unexpected work when refactoring every single agent that we currently have.