that should work if the desktop and ipad are really on the same network, where "network" means "LAN". i assume your ipad is on the wifi, so your desktop would also need to be on the same wifi network, or your wifi must be in "bridge" mode and be an extension of your wired LAN. the IP multicast neighbor discovery uses a TTL of 1, and most home routers wouldn't forward multicast packets anyway.
anothe possible cause could be if your desktop has multiple network interfaces (wired and wireless), and the wired interface is the preferred one. i believe in that case the IP multicast group join will use the physical network interface associated with the default route, so your desktop wouldn't hear the neighbor discovery packets from your ipad over wifi, nor would the desktop be sending its own neighbor discovery packets over wifi.
Yes, that was indeed the issue. My desktop machine is connected via wired connection, while other computers are connected via wifi. If everyone is on wifi, then the system works. Ok, so the obvious next question is: I take it there's no workaround for this? I'd like to create an iOS app that could also be used from a website. But this means that users on a wired connection would not be able to use the app along with iPhone users who'd be connecting via wifi.
Is this a good summation of the situation?
it would work if your wifi network was bridged to your wired ethernet. you can't count on your users having things set up that way, nor could you expect them to make that kind of change to their networks.
there is no reasonable and reliable way for computers to find each other beyond a single LAN without using a server for help (such as the Cirrus service). as i said previously, even if the IP multicast neighbor discovery packets were sent with an IP TTL/hoplim greater than 1, no commonly deployed networking equipment with a standard configuration would forward those multicast packets along to other LANs. we call it "LAN peer discovery" because it is really not going to work beyond one LAN.