Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / [BUG] Linux TCP Sockets

Author
Message
Jack
20
Years of Service
User Offline
Joined: 4th Oct 2004
Location: [Germany]
Posted: 22nd Apr 2020 05:39 Edited at: 22nd Apr 2020 05:41
Link
Hi there.
I compiled the same code of the current AppGameKit version on Linux (Ubuntu) and Windows 10.
I've noticed that TCP sockets are dropped on the linux version after a random time (Between some minutes to over two hours).
The connection on the windows system stays stable. I am using ports less than 1024 and I am running as root.

Has someone a clue, why this happens?
Is it some sort of kernel magic,
settings in /proc/ or a bug that explain the difference?

Back to top
Profile PM Email Website
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 22nd Apr 2020 09:27
Link
Is your network adapter set to go to sleep?
Back to top
Profile PM
Jack
20
Years of Service
User Offline
Joined: 4th Oct 2004
Location: [Germany]
Posted: 22nd Apr 2020 12:51 Edited at: 22nd Apr 2020 12:55
Link
It actually happens during a communication stream :S
During an idle period the tcp socket can be kept for hours with no problems^^
It may be also possible that multiple tcp messages are merged into one, based on wireshark, so first I thought AppGameKit lacks TCP_NODELAY,
but AppGameKit has actually TCP_NODELAY inside each interpreter Linux, Windows, Android, MAC.. (inactive nagle's algorithm) and is top tier style

In my Ubuntu, I can actually inspect my network adapter by using:
ethtool -k enp5s0 (enp5s0 is my adapter but eth0 is more common)

This drops me this data, that can be set somewhere in /proc/ ...net/ipv4...


as I know, the ...segmentation.. is to split the messages into chunks, so they are not interesting here..
generic-segmentation-offload seems quite promising. I would be glad if it's some sort of network adapter thing, because I looked into the linuxnetwork code of agk and it seems very good. I would have no Idea where to look^^

Back to top
Profile PM Email Website
Jack
20
Years of Service
User Offline
Joined: 4th Oct 2004
Location: [Germany]
Posted: 27th Apr 2020 15:44 Edited at: 27th Apr 2020 16:03
Link
Hm, it seems that the linux socket tcp is way more efficient than windows socket tcp.
It may be a problem if I close and reopen a socket in the same loop

for example:


I know, that is way out of the standard...
but the Device I connect to requires a reconnect after a specific time in order to refresh the read buffer....

Right now I close the socket in one loop run, and reestablish another connection in the next loop.
This seems to help.
Lets try a long run first. I keep you updated.

Back to top
Profile PM Email Website
Jack
20
Years of Service
User Offline
Joined: 4th Oct 2004
Location: [Germany]
Posted: 28th Apr 2020 08:59 Edited at: 28th Apr 2020 09:16
Link
So, this is a success. I got a stable connection for 17h now.
The previous code made unrecovable interrupts all 5-15 minutes.

On windows, it is possible to close and reconnect in the same run,
while on linux I have to wait a run in order to reestablish the connection. Right now I run at 200fps
so the time between the close and reconnect is 1/200 of a second, good to know.

I would not call this a bug, but a different way of use tcp on Linux / Windows

Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-11-22 05:35:45
Your offset time is: 2024-11-22 05:35:45