LAN discovery / LAN lobby

[Flamefire]

Add either a LAN discovery (without a lobby server) so one can see open games in the same LAN or make add a server that creates a lobby similar to the Internet Lobby but for LAN mode (dedicated lobby server)

Easy implementation: Use internet lobby server (and ship it with RTTR) but make it usable in LAN. This means:

• Switchable IRC connection (no Lobbybot in LAN)
• Add option to change Lobby server in RTTR (e.g. use same Desktop as for internet but if it is reached via the LAN button, then one has to give the servers IP, which is also stored for next usage)

[Spikeone]

Do we really need a Lan lobby? Most people are able to figure out their IP Adresses and if it's LAN you can tell your mates, that the game is open. Otherwise we could use just one lobby, which shows internet and local games (maybe with icons, (world for interetgame, 2 connected computers for lan)).

[Flamefire]

It was asked by a user who'd need this feature for a bigger LAN party. There could be multiple games going on and when you are in a big room with many people then telling 7 of them your IP across the room is annoying. Also they might not have internet connection so it needs to be local.

We already have a button for LAN. It just does nothing, so why not use that for this?

[Flow86]

we should replace the socket interface

1. with a multithreaded one (I already have a mt tcp server)
2. common interface for tcp/udp.

Now we could use udp on lan (with discovery and faster/easier transfers) and tcp on internet

shipping lobby server does not work withj current design

[Flamefire]

This would be quite a big change. For UDP we also have to implement stuff so that packets are received exactly once and in the exact same order. Without this we will go to async hell. Using UDP for recovery only would be an option. But I'd stick with TCP for the game.

What is the problem? Why can't one just run the lobby server on a different computer than the rttr server?

[Flow86]

if you do udp well, you dont have a problem with inexact order. normal lans dont have that problem (only if you have a multi-path setup, which is non standard)

The problem with the lobby server is: it needs a database access currently and a lot of stuff in there not suitable to be run on a different computer

[Flamefire]

The point is: UDP does not guarantee order and delivery at all. But we need those... Sure over LAN it will work 99% of the time, but why not stick to TCP with this guarantees and deal with the (on LAN even less) network performance impact?

Maybe it can be stripped down? DB access is not really required for something like that. Well except for user managing... Ok I see there would be more work...

[MarcusSt]

I think that supporting TCP should be enough, as it handles all the things we'd have to handle with UDP (and a bit more). By skipping UDP (until we have too much time one day), we avoid having to deal with fancy network-related bugs. :-)

For the dedicated server thing, I'd suggest something like a local discovery (maybe using mDNS or sth that's already out there) or just do it old school style with a UDP broadcast. This could announce a regular "Direct IP" server. We'd just need a "Local Discovery" desktop and some announcement thingy within the Direct IP server.

[Flamefire]

I'm currently testing a really small component that does that (UDP broadcast). It can even use the current socket as we do now (with a small addition of course)

Just doing that while I'm waiting for the memory error analysis to finish which takes ages ;)