search

ValveSoftware / GameNetworkingSockets

Reliable & unreliable messages over UDP. Robust message fragmentation & reassembly. P2P networking / NAT traversal. Encryption.
BSD 3-Clause "New" or "Revised" License
8.12k stars 604 forks source link

Feature Request: LAN Discovery #82

Open james7132 opened 4 years ago

james7132 commented 4 years ago

While this library has shown to scale up to larger server based use cases and cross-continent P2P connections, the lack of a LAN discovery tool for quick and dirty LAN play makes it hard to scale down. I'm working on direct 1v1 games that will largely benefit from avoiding a hop to the nearest relay/authoritative server to establish a game over the same subnet.

zpostfacto commented 4 years ago

It depends on exactly what is meant by discovery. If "discovery" means the ability to ask "is there anybody near me?" and get a list of peers, that might belong in this library, but maybe not. On the other hand, if you want to connect to a peer, and you "discover" that they are on the same LAN, and so you route using local addresses instead of relaying, that I think is absolutely a good thing to have in this API. That will probably part of #64.

I'll keep the first part, the discovery part, open under this bug.

I do realize that only having the second part means that there is some way to know that the other peer exists, and furthermore than you have some identifier you use to connect to them that is not already their LAN address. (If you already had their LAN address you would just use UDP connect.) So in practice it might not serve the needs you are thinking of, and you really do need the true LAN "discovery" bit, too.

james7132 commented 4 years ago

The goal would be to find other players on the same subnet which can then be used for direct, relay-less connection. Usually done by having one host broadcast out to the entire subnet "Hey I have a local server running, connect to me!" and having the others listen for those broadcasts.

The expected use case is something like LAN parties and local play that may not necessitate being on the same physical machine

I understand that matchmaking is generally out of the scope of this library, and that most games nowadays prefer to defer to an authoritative remote server, but these discovery protocols often operate at the same level as this library, and this would be immensely useful for P2P games.

On Tue, Jan 7, 2020, 3:36 PM Fletcher Dunn notifications@github.com wrote:

It depends on exactly what is meant by discovery. If "discovery" means the ability to ask "is there anybody near me?" and get a list of peers, that might belong in this library, but maybe not. On the other hand, if you want to connect to a peer, and you "discover" that they are on the same LAN, and so you route using local addresses instead of relaying, that I think is absolutely a good thing to have in this API. That will probably part of

64 https://github.com/ValveSoftware/GameNetworkingSockets/issues/64.

I'll keep the first part, the discovery part, open under this bug.

I do realize that only having the second part means that there is some way to know that the other peer exists, and furthermore than you have some identifier you use to connect to them that is not already their LAN address. (If you already had their LAN address you would just use UDP connect.) So in practice it might not serve the needs you are thinking of, and you really do need the true LAN "discovery" bit, too.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/GameNetworkingSockets/issues/82?email_source=notifications&email_token=AAX6BEBDET5YINMAVLS2A4TQ4UGZBA5CNFSM4JQALPZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIKVNOI#issuecomment-571823801, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAX6BEBIU3RU4HLAPXVCE33Q4UGZBANCNFSM4JQALPZQ .

zpostfacto commented 4 years ago

Yeah, that's what I thought you meant. I agree that it is not totally out of place in this library.

Several design decisions to think through about exactly what interface the API exposes, whether the server sends out broadcasts or is only listening for searches that are broadcasts by clients, whether the beacon is the same port as the listen socket, or is conceptually a separate entity, etc. And also what the relationship between anything we add here and existing Steamworks features. Does it use the Steam protocols, etc, etc. Lots of decisions to think through.

Do you know of other APIs that you think did a good job with this?