Skip to main content
GameDev.net gamedev.net
🔒 Locked

LuaSocket question

Started by rpiller Aug 25, 2011 at 4:45 PM 0 replies 1.6k views
Original Post
rpiller
rpiller
So reading through http://www.ozone3d.n...cket_lib_p4.php

Looking at the code for the server and had a few questions hoping someone has experience with:

In the article he states this method could be placed in the main game loop. That makes sense but I fail to see why this needs to be setup as a coroutine if that's the case. After each loop of this method it yields back out. How would that be any different than just running this function without the while loop and without it being a coroutine? It sets it's timeout to 10ms and no matter if it's a coroutine or not the program will end up waiting 10ms.

Also this code looks like it accepts a connection and reads the data. In TCP isn't the connection persistent? Here he is accepting and getting the data then closing. That doesn't seem logical for a real game. So does anyone know how to manage connected clients and how to determine disconnected clients with this library? I would think accept() gives you some sort of unique id that I could store off and receive() would give me that same id so I know who it came from and send() would allow me to either broadcast or send to a specific id.



function runTCPServer()

local stop_server = 0;
local num_cnx = 0;

while( stop_server==0 ) do

local err = "";
local tcp_client = 0;

-- Set a timeout of 10 ms for accept().
--
g_tcp_server:settimeout(0.01);
tcp_client, err = g_tcp_server:accept();

if tcp_client~=nil then

-- client message must be terminated by
-- terminated by a LF character (ASCII 10),
-- optionally preceded by a CR character (ASCII 13).
--
g_client_msg, err = tcp_client:receive('*l');

if( g_client_msg~=nil ) then
if(g_client_msg=="STOP") then
stop_server = 1;
else
-- tcp_client:send( "Demoniak3D TCP Server Echo: " .. g_client_msg);
end
end

if tcp_client~=nil then
tcp_client:close();
end
end

-- Yield execution.
--
coroutine.yield();

end
end
hplus0603
hplus0603

In the article he states this method could be placed in the main game loop. That makes sense but I fail to see why this needs to be setup as a coroutine if that's the case. After each loop of this method it yields back out. How would that be any different than just running this function without the while loop and without it being a coroutine? It sets it's timeout to 10ms and no matter if it's a coroutine or not the program will end up waiting 10ms.

Also this code looks like it accepts a connection and reads the data. In TCP isn't the connection persistent? Here he is accepting and getting the data then closing. That doesn't seem logical for a real game. So does anyone know how to manage connected clients and how to determine disconnected clients with this library?




It may be that the code is intended to only be an illustration. However, I would say that it doesn't inspire much confidence -- most of your complaints seem quite valid.

After you start writing real code, and testing real code in production, and learn how to write real systems, a lot of the "tutorials" and "engines" on the internet start looking like what they are -- the insecure first steps of someone who is learning software engineering. This is why engines written by experienced people and tested over time generally cost a lot of money.

Note that I'm not saying that all free engines or libraries are bad, or that all pay-for engines or libraries are good. However, most free libraries are written by young, enthusiastic people with lots of time on their hands, who aren't actually the kind of people that you'd really want to create the foundational infrastructure that your large-scale system is going to be built on.

Begin rant: Sadly, large parts of the game industry itself has this same problem, because it pays poorly, and often values time in the office over real-world results. Anyone who wants to have a life will get out after a while, which means that most of the experienced, senior people that could fix the technical problems are nowhere to be found. And they will not return back to games, because most game studios would rather hire a fresh recruit for half the cost and work him to exhaustion. And then lay him (or her?) off after he showed the dedication and loyalty to stick around until the the game shipped. The entire industry (and medium) seems to be set up such that this is the most common model, and I don't have any bright ideas about how that might be fixed.
enum Bool { True, False, FileNotFound };

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.