LÖVE

Hello,
I am trying to network my game between client and server using Luasocket. However, I am having issues with getting consistent responses for fetching the world, especially when multiple clients are connected and disconnected. I wanted to ask if you could please review my code and let me know how I can improve it, so that I have consistent client connection/disconnections, and my server promptly responds to clients.

Here is the .LOVE files:
server: client: Here is also a Github repository (same code as above):
https://github.com/EliterScripts/tank-g ... aster/test


I ran this on Ubuntu Desktop (LTS 18.04) terminal. I found it easier to run the client by installing Luasocket via luarocks, and running "lua5.2 main.lua" directly from Lua 5.2. It helps a lot with simulating client abrupt termination by using ctrl+C in terminal. I'm not sure how to make the client abruptly disconnect using LOVE. However, I used LOVE2D to run the server.

To use Luasocket with Lua on Ubuntu/Debian Linux:
Install Luasocket via Luarocks:
Steps to Reproduce:
1. Rename "client.love" to "client.zip"
2. Unzip "client.zip"
3. Start server (in new terminal): 4. start first client (in new terminal): 5. start second client (in new terminal): 6. end second client (using ctrl+C)
7. start second client
8. You can close all the terminals and processes now.

To reproduce WITHOUT installing Luasocket via luarocks:
1. Start server (in new terminal): 2. start first client (in new terminal): 5. start second client (in new terminal): 6. end second client (using ctrl+Z)
7. start second client
8. You can close all the terminals and processes now.


Expected Results:
While the server and client(s) (is/are) on localhost, I expect the message from the client to the server to be accepted, processed, and responded to within less than 0.05 seconds, consistently, without the TCP connection dropping, regardless if or not if: it is the first time the client has been connected, disconnected, there are multiple clients connected to the server, or first time the server has connected to a client. I also expect that the server and client break/close the TCP connection if there has been no communication within 3 seconds, and the server delete any client objects when this happens.

Actual Results:
1. After step 1 ("Start server"):
The server starts, (output: https://paste.ubuntu.com/p/JBRsk8c6W5/), satisfactorily.

2. After step 2 ("start first client"):
The client connects, (output: https://paste.ubuntu.com/p/FfRvxpFSv3/), somewhat satisfactory. I don't like nor understand how/why it times out every other packet. However, the client is still receiving data.
The server accepts, (output: https://paste.ubuntu.com/p/SYdk6wvwPg/), somewhat satisfactory. I don't like nor understand how/why there is no consistency with the timing between the client sending data and console output.

3. After step 3 ("start second client"):
The second client connects, (output: https://paste.ubuntu.com/p/JjqJ6J9HNJ/), not satisfactory. I don't like nor understand how/why there is no consistency between timing out and received server message. It has a lot more packets that timed out than I want, every other 2-5 packets actually get received.
The first client (output: https://paste.ubuntu.com/p/QPgKGcSgrc/), not satisfactory. I don't like nor understand how/why packets start to time out more often when the first client connects.

4. After step 4 ("end second client"):
The second client disconnects (via ctrl+C).
The first client continues to drop more packets after the second client disconnects. (first client output: https://paste.ubuntu.com/p/TwPF2DySPK/).
The server disconnects with the client (output: https://paste.ubuntu.com/p/79rTqzx36H/) somewhat satisfactory. I think it keeps printing "clients: 2" far too long after the client has disconnected.

5. After step 5 ("start second client"):
The second client connects, but has %100 timeout packets (output: https://paste.ubuntu.com/p/HBnjdPZvbd/), absolutely unacceptable.
Server output: https://paste.ubuntu.com/p/RKBBWVqDsQ/


I really hope I was clear. I have tried this several times, and have failed. Please let me know if I need to provide any more details.


Thanks!


I apologize for duplicating threads, as I was not getting a response, and figured I would use a more appropriately named thread to ask for help.

Hey, so I have not gotten a response on this issue. Did I include enough information? Am I asking the wrong questions? Do I seem lazy in my attempt?

I'd assume it's more because people don't have either the time or knowledge to help you debug this issue; networking is hard. i sincerely doubt it'd be a personal reason though.

I do believe you provided lots of information, and i'm assuming you didn't use lua 5.2 specific features in your code because it'd not run with löve by default (that using luajit without the 5.2 compatibility flag set)

The questions shouldn't matter much if you detailed your issue this much; and you probably did put tons of effort into this, but again, networking is hard to debug.

Now maybe after i said it's hard to debug, maybe someone will step in to correct me and offer a solution for you.
If not, i might test something out myself soon, but not today.

The code is somewhat hard to follow for me. What I could notice is an alarming lack of calls to socket.select(). Also, sockets typically have either a high timeout (if they're designed to be blocking) or a zero timeout (if not), because socket.select() usually does the wait.

For an example of a (collaborative) multi-threaded socket implementation, see http://www.lua.org/pil/9.4.html (I think it's based on an old version of LuaSocket).

I've always had trouble understanding how to handle closing of TCP connections. I believe that they are resource heavy, and that's what makes UDP more widely used in gaming. I don't know how many games use TCP for their communication protocol, but I don't think there will be many. I know for sure of two examples that use UDP for updating clients: Minetest and Second Life. I also know that Second Life uses HTTP for transmitting certain assets like textures. It used to use a custom UDP-based protocol, but it seems that couldn't be used with a CDN when the need arose.

TCP connections also have the problem of "half-open connections", where the client "pulls the plug" without closing first, and the server doesn't receive the closing request, and the only thing the server can do is time out. See this Q/A for a discussion: https://stackoverflow.com/questions/209 ... tcp-socket

Okay, so I took your suggestion to use socket.select(), which worked excellent. What I am going to do is have BOTH TCP and UDP on the same IP/port on both sides, and switch between either as needed. I have found that my packets for sending the world are a bit large and found that TCP is much easier to work with for larger strings.

I figured out how to get excellent response times, while still maintaining a consistent connect/disconnect rhythm, dropping the connection when the client doesn't respond in whatever amount of time (under 2 seconds).

I am now restructuring my actual client code now that I have networking working good enough to send/receive data, now I have to create players when they join, and make them move left when you hit "A".

I would like to work on getting HTTP working between the client and the server, since HTTP is a very well defined and supported protocol with many features.

Now I know HTTP is designed to connect, fetch data, and disconnect, so I will be making my own game's protocol, but I want my client/server to communicate/negotiate over HTTP before using my custom protocol. This is so if I need to eventually add load balancers, redirect or whatever other complex features, I don't have to program that into my game's protocol, I'll just use another tool (like Apache/nginx) to redirect/proxy traffic, with no changes needed to the client (since I think Luasocket HTTP client uses common sense when it is being redirected).

You may want to take a look at https://en.wikipedia.org/wiki/HTTP_pers ... connection