Windows client cannot open a new multiplayer room in the online lobby

[Andy]

The button to open a new room is disabled on the online lobby. Direct TCP\IP connection works fine.

[SirVer (sirver)]

Jari, could you please verify this?

[Jari Hautio (jarih)]

Confirming that GGZ multiplayer hosting support is disabled in windows builds. It's disabled because GGZ server wont show up any games hosted in windows machines. Widelands side seems to be ok, so there's propably a bug in GGZ windows code.

Peter notified me about this issue with mingw builds earlier and I confirmed the same with MSVC builds.

I can check this out a bit deeper.

[Victor Pelt (victor-pelt)]

could you confirm if it's still an issue with recent ggz versions?
if it's fixed in ggz 0.99.x then we could at least make static versions that allow windows users to host games

[Jari Hautio (jarih)]

MSVC build was tested with latest trunk 10948 with some mods for msvc (lp:~jarih/+junk/ggz-baselibs-msvc). Mingw builds also must use fairly recent trunk as released windows binaries 0.99.5pre are broken, but I cannot test mingw build. GGZ baselibs have been stable for 8 month and there propably is not much windows efforts going on.

[SirVer (sirver)]

This means that ggz is unable to let windows machines host games? This is a serious bug I wasn't aware of. No chance to fix this before build15 I guess, but we must tackle this for build16. Damn, this ggz is one b*** piece of software. Aren't there any alternatives?

[SirVer (sirver)]

Jari, if you do not feel like looking into this, feel free to unassign you from this bug. I just assigned you for verification. Thanks for that ;).

[Jari Hautio (jarih)]

Yes, windows machines are unable to host games with GGZ. I can look into this. I already have debug builds of ggz libraries and have debugged it a bit.

[Jari Hautio (jarih)]

Having an additional ggz processing round in NetGGZ::connect gives me a green server in GGZ. However it's a bit hard to test playing from NATted lan.

 while (ggzmod_get_state(mod) != GGZMOD_STATE_PLAYING) {
  select(fd + 1, &fdset, 0, 0, &timeout);
  ggzmod_dispatch(mod);
  //log("GGZ ## timeout!\n");
  if (usedcore())
   datacore();
 }

+ ggzmod_dispatch(mod);
+ if (usedcore())
+ datacore();

[Jari Hautio (jarih)]

Got around my NAT. If server goes green, connection will succeed between two windows machines. Still I get sometimes red server icon. After multiple test runs it looks like a timing issue. If ggzmod_server gets fd after channel connected event, server goes red, otherwise it goes green.

From stdout.txt this gets red (nonfunctional) server
>> GGZ: initialized
GGZ ## connect
GGZ ## connection fd 972
GGZCORE/game ## callback: 2
GGZCORE/game ## -- negotiated
GGZCORE ## callback: 17
GGZCORE ## -- channel connected
GGZ ## ggzmod_server
GGZ ## got fd: 964
GGZCORE/game ## callback: 4
GGZCORE/game ## -- playing
GGZCORE ## callback: 18
GGZCORE ## -- channel ready

and this gets green, working server:

GGZ ## connect
GGZ ## connection fd 976
GGZ ## ggzmod_server
GGZ ## got fd: 932
GGZCORE/game ## callback: 2
GGZCORE/game ## -- negotiated
GGZCORE ## callback: 17
GGZCORE ## -- channel connected
GGZCORE/game ## callback: 4
GGZCORE/game ## -- playing
GGZCORE ## callback: 18
GGZCORE ## -- channel ready

[SirVer (sirver)]

Jari, on what are you working here? Is this widelands code or GGZ code?

[Timowi (timo-wingender)]

This is widelands code.

ggz is in a quite early state and has some problems. I do not know an alternative to ggz. We should stay with that and wait until it is finished or help them a bit.

This problem is caused by the way how widelands integrates ggz. Normally ggzcore and ggzmod are used in two different programs but we use ggzcore embedded. Widelands was the first and is almost only program which use ggzcore this way. This bug seems caused by the same problems as the "only 7 or 8 seats per table or widelands hangs" bug. I started to discuss this with the ggz devs but there is not much going on at the moment.

The ggz code in widelands needs some improvements. This is done in widelands-server branch. There will be some changes to ggz implementation on server and client side. These should fix these bugs. We should leave open game with ggz disabled under windows for build15.

[SirVer (sirver)]

okay.

[Jari Hautio (jarih)]

I think I got it sorted out. The problem lied in widelands code that handled reading GGZ sockets. I got five succesful game launches with two fixed windows clients. I could not reliably connect to server, if client machine had RC2.

I added the fix to branch lp:~jarih/widelands/fix-windows-gzz-host. I'd like to test it also on linux machine before commiting to trunk. Also comments are welcome. I'm not quite sure using whiles for reading ggz_mod socket is best thing to do, but it works.

[Victor Pelt (victor-pelt)]

initial test shows it freezes on linux
output below. will try to debug it more tomorow

GGZCORE ## initialization
GGZCORE ## callback: 0
GGZCORE ## -- connected
GGZCORE ## start loop
GGZCORE ## callback: 2
GGZCORE ## -- negotiated
GGZCORE ## callback: 4
GGZCORE ## -- logged in
GGZCORE ## callback: 6
GGZCORE ## -- motd loaded!
GGZCORE ## callback: 8
GGZCORE ## -- (type list)
GGZCORE ## callback: 7
GGZCORE ## -- (room list)
GGZCORE ## callback: 10
GGZCORE ## -- entered room
GGZCORE/room ## callback: 1
GGZCORE/room ## -- table list
GGZCORE ## end loop
GGZCORE/room ## callback: 0
GGZCORE/room ## -- user list
[Host] starting up.
GGZCORE ## launch table
GGZCORE/game ## callback: 0
GGZCORE/game ## -- launched
>> GGZ: initialized
GGZ ## connect
GGZ ## connection fd 53
GGZCORE/game ## callback: 2
GGZCORE/game ## -- negotiated
GGZCORE ## callback: 17
GGZCORE ## -- channel connected
GGZCORE ## callback: 18
GGZCORE ## -- channel ready
>> GGZ: initialized

[Victor Pelt (victor-pelt)]

also need to add

+/* Check for incoming data */
+/// \note The FD_SET macro from glibc uses old-style cast. We can not fix this
+/// ourselves, so we temporarily turn the error into a warning. It is turned
+/// back into an error after this function.
+#pragma GCC diagnostic warning "-Wold-style-cast"
+int NetGGZ::data_is_pending(int fd)

this is to make it compile with gcc

[Timowi (timo-wingender)]

I am completely against changing the ggz behavior before build15. This likely will introduce more bugs. The ggz implementation is quite basic now and it should be reworked before build16. Adding such workarounds will just trigger new bugs.

[Victor Pelt (victor-pelt)]

timowi, don't worry. notice how this bug is tagged as build16-rc1 and it's being developed in a seperate branch

[Jari Hautio (jarih)]

Ok now it works on linux and windows. I tested up to transferring IP address using linux host and windows host. But testing further is a bit awkward in my NAT:ted home network.

I agree that targeting build16-rc1 is wise, so I'm not hurrying with commiting to trunk until build 15 is out. These changes need longer testing time as I don't fully understand the reasons why all the fixes were needed.

[Timowi (timo-wingender)]

It looks a lot like short term workarounds. Thats why I've written about "not for build15".

The ggz issues should really be fixed for build16. There must be no timing or order of actions issues in the ggz implementations. This is not only related to windows hosting but causes some more bugs. And code breaks quite easy because of this. The Problem is how (and that) we use ggzcore and ggzmod from one program. I've debugged these problems already and I know how to fix these. But I want to do this "the ggz way". I think it makes no sense to to go our own way to use ggz this way. These changes should go in ggz. Thats why I want to discuss it with them. Other games will (hopefully) benefit from our work later.

[Jari Hautio (jarih)]

Timo, I did not know that you already know how to fix this properly. I did not want to touch the logic part and wanted to keep patch as small as possible, so I just kept close to socket reading code. So if you know how to fix it properly, I'll gladly let you do it the right way and leave this fix to branch.

Just to complete the branch, I made same final touches to make the patch smaller and nicer. I also tested it through hosting three games under windows and linux. The short term workaround is contained in the NetGGZ::connect function. Other parts are imho required for correct and safe funtionality in windows and should not cause any side effects.

I dont know how well windows side has been tested, but I had some problems when testing with downloaded build15-rc2 on windows and linux server without my fix. When windows client tried to join a game, I got an error message saying connection timed out and could not get IP address. Client was kicked back to main menu. When I tried to enter lobby again with same user id, I got error message Already logged in. Restarting widelands removed old logins. I had try four or five times to get to join a game. With the fix in, I never had problems to join a game.

[Jari Hautio (jarih)]

Merged to trunk in 5461.

[SirVer (sirver)]

Released in build16-rc1