Can we do an IP (or ARP) broadcast from the Pi to find other Pis?

[neilcollins]

The reason this would be useful is that it would be nice when the kids first kick off the program running on a school network or local LAN that it does something. For example it might print up a message like:

Pi Conga : waiting to see if there are any other Pis about....

And then go on to say which it's found and then say "Let's Conga..."

[ZsigE]

That could work, but I think we need to define how a Conga is started and owned. Might it make more sense to have the Pi only do the broadcast when we try to start a Conga? Then you could start the software on your Pi in either "host" mode (broadcast the Pi's hostname and the name of the Conga it's starting) or "join" mode (listen for those broadcasts - the user can then choose one of the Congas it's found, and can send a message to that host saying "hello, I'd like to join your Conga").

[Lukasa]

Technically speaking it's not a challenge. I've whipped up a quick example (in the broadcast directory). A simple server listens on a specific UDP port for any message, and we send broadcast packets out. Run the server on your local box then execute the client a few times to see what I mean.

This only works for LANs, though: I'm pretty sure this doesn't fly on the actual internet. =)

As to Philip's notion, I think we don't need to do all that. The cleanest way to handle this seems like:

1. Launch the conga software in 'LAN' mode.
2. Send out a broadcast packet.
3. Any Pi that is at the end of a conga (i.e. has no partner to send data to) sends a message saying 'Hi, want to join my conga?'
4. Send a message saying 'yes'.

If, after a few broadcasts, the Pi doesn't hear anything, it goes 'oh well, I'll start a new conga myself' and puts itself at the end of a conga of one, waiting for future broadcast packets.

[Lukasa]

There are a few other technical difficulties. We'll need to either use an event loop (e.g. Twisted, which isn't exactly newbie friendly) or use multiprocessing for this passive listening stuff, to avoid blocking the main thread. We'd also need some sort of dispute-resolution: if two Pis somehow miss each other's packets on the LAN and start their own congas, how does a Pi handle getting two responses saying 'join my conga!'?

[peterbrittain]

Possibly this then becomes one of those invisible extras for kids who delve a little in the code? The default version simply asks you what you want to do - register/create/join/etc - and so no dispute resolution required. The optional extra can start up another thread that does the passive listening - which feeds into extra options in the client.

But before we can make too many decisions about the client design, don't we need some sort of plan for the UI? Is this going to be a simple text CLI, some sort of terminal CLI (e.g. based on curses) or are we looking for a native GUI (e.g. http://wiki.python.org/moin/TkInter).

The nature of that UI is going to determine a fair bit of the complexity of the mainlin dispatch loop. Worth rasing this as a new Issue?

[neilcollins]

Good point Peter. See #4.

[Lukasa]

As for this being an 'invisible extra', I think you're right. There's going to be a decent quantity of code that will be difficult for new children to work with. We'll just need to hide it behind a descriptive API.

[peterbrittain]

Given that you created the sample code, I assume you're happy to own the API for this feature, Cory.