kmar / livius

livius - a Qt-based TLCV-compatible live chess viewer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Livius doesn't ACK UDP packets

hazzl opened this issue · comments

Hi there, thanks for writing this.

Unfortunately, I don't have any success connecting to games using livius when compiling against Qt5.5. Inspecting the packet stream with the server shows that the server responds to the LOGONv15: request normally. However, livius does not seem to register the replys. It doesn't ACK the packets and soon after just sends a LOGOFF message.

Hm, the problem seems to be with signal processing. TLCVClient::receive() never gets called.

commented

Hi, I haven't tried to compile against Qt5.5,
there's still another comm problem,
namely that sometimes the server kicks Livius without the client noticing it so one has to reconnect manually which is annoying.
I still use my old 4.8 compile to connect to Graham's tournaments (works).
I should probably look into this but the project is no longer actively developed, not sure.
I could at least try to compile with 5.5 and to see what's wrong.
And thanks for reporting this issue, if you by any chance find a workaround I would gladly accept a patch.

commented

sigh I just tried to install Qt5.6 (what's cute about installing 20 gigabytes of precompiled libraries?) and I figured out they removed QtWebkit, instead they use QtWebEngine now,
not to mention I wasn't even able to setup a proper kit...
Old QtCreator (4.8.4) used slightly over 100M of RAM, now they use 500M, again what's cute about it?
I think it's going downhill... I wasted a hour for nothing so I suggest to switch to older Qt version...
Sorry... don't have time for this...

I have identified the problem. It's in UDPClient::receive(). To filter out unrelated UDP streams we compare that the received datagram matches expected size, port and host. For whatever reason, my system defaults to listing received packets as IPv6 addresses in the form ::ffff:IPv4 so the string comparison against the pure IPv4 address fails and the packet is discarded.

Easy fix is to convert both addresses to IPv4. It would be future proof if we could convert both addresses to IPv6. But I didn't manage that quickly. Any ideas?

I also cannot connect to Graham's tournaments. Recently, I switched my provider and now have IPv6, too. The last time, I successfully connected was still on IPv4.

GrahamCCRL.dyndns.org:16053 seems to be most current URL. Is that right? Do you know a URL, which can be used for testing?

At the moment, I am not sure if I have run into the bug you described, or if I just use the wrong URL.

I'm currently using port 16084. You could just check the CCRL forum for active broadcasts.

commented

Thanks people, merged. I'm closing this issue.