Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Running Two NetworkDiscovery Scripts At Once?

Discussion in 'Multiplayer' started by eshan-mathur, Feb 6, 2016.

  1. eshan-mathur

    eshan-mathur

    Joined:
    Nov 22, 2011
    Posts:
    118
    The Local Discovery manual page contains the following tidbit:

    As a point of clarity, does this mean there is absolutely no way to use NetworkDiscovery to both broadcast and listen at the same time?

    I'm trying to figure out a way that two phones can discover each other over a Wifi network without any sort of user input (i.e. no explicit choice of who is broadcasting and who is listening).

    I was thinking of trying to run two instances of NetworkDiscovery at the same time, with one listening and one broadcasting. They would know to ignore their own device's broadcast, but would be able to pick up another device. However, "in the same process" makes it sound like one device can never do this?
     
  2. Munchy2007

    Munchy2007

    Joined:
    Jun 16, 2013
    Posts:
    1,732
    I did it by starting as client by default, so it's listening as soon as you start up the game and can immediately see any available sessions.

    And then if you want to host a game instead, just stop the current listening broadcast and restart it as a server when you click your 'host game' button.
     
  3. eshan-mathur

    eshan-mathur

    Joined:
    Nov 22, 2011
    Posts:
    118
    Ideally I'm looking for a way to connect the two devices without anyone having to push a button. The most seamless experience would be you start up the app on both devices and they just find each other.
     
  4. Munchy2007

    Munchy2007

    Joined:
    Jun 16, 2013
    Posts:
    1,732
    Well I guess, you could have the game start up in listening mode, and then if it doesn't find a game it automatically stops listening and starts a host.

    Obviously the other device would find the game when it starts up in which case you would just have it join automatically.

    Seems simple enough.
     
  5. eshan-mathur

    eshan-mathur

    Joined:
    Nov 22, 2011
    Posts:
    118
    First of all, thanks for taking an interest in the problem!

    In most cases that would probably just work. Would be curious to know your thoughts on the following problems with that approach:
    1. What if there is a 3rd device on the network that we do not want to connect to? Let's call it Device Z. If Device Z has been around long enough to be a host now, and Device A starts up with the intention of connecting to Device B, but the moment it starts up it catches Device Z instead, leaving Device B all by it's lonesome when it starts up. I suppose a button to go back to the connection screen could solve this - Device B would probably be in host mode by the time Device A realized it connected to Device Z, but it's a pity that the user has to undo something that the device did.
    2. Let's say Device A and Device B start at roughly the same time, with Device A starting a very short amount of time earlier. Depending on how long it takes the switch from listening to broadcasting takes, it's conceivable that Device B might never connect to Device A because they were both "listening" for 99% of their time and the only time delta between the two being in different states is so small that Device A isn't finished switching to host mode before Device B also begins it's switch. One solution I'm thinking of is having each device flip back and forth between listening and broadcasting but with a little time variance so they can catch each other even if they started at the same time.
     
  6. Munchy2007

    Munchy2007

    Joined:
    Jun 16, 2013
    Posts:
    1,732
    Taking point 1 first, I don't think you can have a your wish of a completely interaction free connection system, but at the same time arbitrarily exclude connection to other devices. It has to be, by it's very nature, a 'first come first served' system.

    Unless of course you pre-programmed some kind of pairing system into the two devices beforehand, but that would limit them to only connecting to their matched device. So not such a good idea really.

    Regarding point 2, to avoid the possibility of deadlock as you described, then your solution to switch between broadcast and listening should work well enough.
     
  7. eshan-mathur

    eshan-mathur

    Joined:
    Nov 22, 2011
    Posts:
    118
    For point 1, now that I think about it, even backing out to the listening state won't work because that means Device Z will also back out into the listening state, and then it's a race between Device A and Z to see who pairs with the now likely-host, Device B.

    Have you seen Spaceteam's connection process? All devices seem to just find each other and not care about who is listening and who is broadcasting. During the finding process, there is no interaction or choice made by the user, really.
     
  8. Munchy2007

    Munchy2007

    Joined:
    Jun 16, 2013
    Posts:
    1,732
    Even in a situation where the app could listen and broadcast at the same time, there could still be the issue of contention when two devices are started simultaneously.

    They'd both become servers initially, and even though they would, by virtue of being able to listen at the same time, become aware that there was another server started, how would they decide which one was to switch roles?

    I can't think of a method that would work in every case without some kind of user interaction. I haven't seen the game you mentioned, however I can understand exactly what you're after, I just can't figure out a way to do it with the UNET HLAPI as it currently stands.
     
  9. eshan-mathur

    eshan-mathur

    Joined:
    Nov 22, 2011
    Posts:
    118
    If they knew to ignore their own self broadcast, then they could pick based on IP address, couldn't they? Whoever has the higher number wins and becomes the broadcaster, the other guy shuts his broadcaster off and says "I'm ready to connect as a client."

    Also, here's a video I just made of two devices connecting in Spaceteam, for your reference.



    The only interaction there is the dial, which presumably only functions to say "I want to connect to something".
     
  10. Munchy2007

    Munchy2007

    Joined:
    Jun 16, 2013
    Posts:
    1,732
    `
    This would require communication between the devices to make the comparison, which won't be possible with UNET before the devices have connected to each other.
     
  11. eshan-mathur

    eshan-mathur

    Joined:
    Nov 22, 2011
    Posts:
    118
    If you could have two NetworkDiscovery instances up and running, their broadcast data could contain the IP address. But it doesn't look like that's possible...

    So the only solution then is to use the LLAPI and write our own version of NetworkDiscovery that can run simultaneously with itself?

    Another alternative maybe would be to just have one button (a "I'm the host!" button, or something) that manually pushes a device into hosting mode. This way the listening device can just find it, or in the case of multiple hosting devices, can have you choose from a list. Still better than two buttons.
     
  12. hengineer

    hengineer

    Joined:
    Mar 18, 2013
    Posts:
    13
    For anyone else interested in this topic, I'm running two NetworkDiscovery scripts on two different objects (one to broadcast and one to listen) and it seems fine so far. Fingers crossed!
     
  13. eshan-mathur

    eshan-mathur

    Joined:
    Nov 22, 2011
    Posts:
    118
    Thanks for your courageous exploration! :)

    I'm wondering if it's best to submit an error report with the documentation.
     
  14. Munchy2007

    Munchy2007

    Joined:
    Jun 16, 2013
    Posts:
    1,732
    That never even occurred to me, I'll have to try that myself, thanks.
     
  15. Munchy2007

    Munchy2007

    Joined:
    Jun 16, 2013
    Posts:
    1,732
    I had tried two networkdiscoveries on the same gameobject, and I ran into problems.

    I didn't think putting them on two different gameobjects would make any difference, so I didn't try it at the time. I still can't see why it would make a difference, but I haven't got around to trying it myself yet.
     
    eshan-mathur likes this.