Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I built a library for purely cross-platform programming. My games made with it run fine in Android , Pc, Linux, Mac etc.

The networking capabilities are provided by ENET library, therefore all communication between my apps is not TCP or UDP compatible, but only in the custom protocol, even tough its based on the UDP ultimately.

I don't think its possible to do what i want with ENET, thats why I ask here for help!

Lets say I have the same game running in my Android phone, my laptop and my pc. They are all in the same wifi network, and therefore in a LAN, whether its Wifi hotspot(?) or the household router.

I need each of those 3 peers to discover the other two in the network. This is meant only to find the IP of alive apps in the LAN network, to be able to host multiplayer games between them.

I can only think of one effective way to do this, UDP broadcast, wait responses, but if that is the solution, i need something small, since its the only purpose of the implementation.

Other way could be to try to connect to all IPs in the LAN address subrange, but I don't think the OS would be with me on this one :p

Sorry for the long question!

share|improve this question
2  
I think a few UDP broadcasts are the way to go, and I don't understand your objections to it, or is it that ENET doesn't support broadcasts? –  Roy T. Jun 18 '12 at 7:42
    
Exactly, it doesn't, it can only broadcast to already known peers.. –  Grimshaw Jun 18 '12 at 11:25
    
stackoverflow.com/questions/683624/… Does this influence an answer? –  Grimshaw Jun 18 '12 at 14:30
add comment

2 Answers

You could have a look at DNS-SD/ZeroConf/Avahi/Bonjour/mDNS. It's the stuff Apple use to share printers, iTunes folders and so on but it's been adopted elsewhere. Avahi is the opensource version that Linux uses (not sure if it's Linux only), not sure how portable the whole thing is (although there are implementations for most platforms).

Having said all that, it's probably easier to just do the UDP broadcast.

share|improve this answer
add comment

When you don't want to leave your library, you could just use brute-force and attempt to connect to each one of the possible addresses. Most home lans are Class-C networks (/24) where the first 24 bit of the IP address are the same and the last 8 bit differ. So you only have 255 possible IP addresses.

But still, doing an UDP broadcast would be the cleaner alternative. Just send an UDP packet to 255.255.255.255 and all clients behind the same router will receive it. They can then send a reply to the source IP and source port of the packet to inform the sender that they are present.

share|improve this answer
    
Please please please please please don't brute-force. –  Trevor Powell Jan 15 '13 at 0:25
    
@TrevorPowell ...because...? –  Philipp Jan 15 '13 at 8:21
    
Because it's the wrong solution. It won't work in universities (which do not use class-c networks) or at businesses (which also typically do not use class-c networks), and the IT staff at either will intensely dislike the load caused by having every player make brute-force attempts to send messages to every IP address in their network every time they click a 'refresh' button. It's just a bad solution to the problem. This question of locating potential peers without a mathmaking server is precisely what broadcast is for. Use broadcast. It's better in every way. :) –  Trevor Powell Jan 15 '13 at 9:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.