IRCLogs • ArmaNelgTron.tk

Log from 2016-07-18:
Jul 18 00:18:08 2016 <luke-jr>	http://luke.dashjr.org/tmp/screenshots/snapshot148.png
Jul 18 01:10:32 2016 *	ct|kyle has quit (Remote host closed the connection)
Jul 18 02:04:10 2016 <Lucifer_arma>	luke-jr: next time, say "For Pokemon Go stuff that nobody cares about"
Jul 18 12:51:47 2016 *	G5 (~g5@p2003006A6A7BA20009560C9D1DBF50CA.dip0.t-ipconnect.de) has joined #armagetron
Jul 18 13:05:44 2016 *	theocrite_ has quit (Ping timeout: 272 seconds)
Jul 18 13:05:45 2016 *	\u03b5 has quit (Ping timeout: 272 seconds)
Jul 18 13:06:12 2016 *	theocrite_ (~Jean-Mari@2a03:7220:8080:f800::1) has joined #armagetron
Jul 18 13:06:23 2016 *	luke-jr has quit (Ping timeout: 272 seconds)
Jul 18 13:06:24 2016 *	P4 has quit (Ping timeout: 272 seconds)
Jul 18 13:12:53 2016 *	luke-jr (~luke-jr@unaffiliated/luke-jr) has joined #armagetron
Jul 18 13:12:57 2016 *	p4 (~P4@2a03:b0c0:0:1010::14a:8001) has joined #armagetron
Jul 18 13:12:57 2016 *	p4 has quit (Changing host)
Jul 18 13:12:57 2016 *	p4 (~P4@unaffiliated/p4) has joined #armagetron
Jul 18 13:13:08 2016 *	\u03b5 (~epsy@unaffiliated/epsy) has joined #armagetron
Jul 18 16:29:06 2016 *	G5 has quit ()
Jul 18 19:16:55 2016 *	p4 is now known as P4
Jul 18 20:21:18 2016 *	ct|kyle (~kyle@184.18.134.169) has joined #armagetron
Jul 18 21:09:05 2016 *	Lucifer_arma has quit (Read error: Connection reset by peer)
Jul 18 21:10:19 2016 *	Lucifer_arma (~Lucifer_a@cpe-66-68-59-243.austin.res.rr.com) has joined #armagetron
Jul 18 21:55:24 2016 *	zmanuel (~Z-Man@p4FC16DA9.dip0.t-ipconnect.de) has joined #armagetron
Jul 18 21:55:24 2016 *	Z-Man has quit (Killed (verne.freenode.net (Nickname regained by services)))
Jul 18 21:55:24 2016 *	zmanuel is now known as Z-Man
Jul 18 22:28:27 2016 <Lucifer_arma>	so here's an idea
Jul 18 22:28:47 2016 <Lucifer_arma>	let's say you're suffering packet loss so badly that two out of every three packets goes missing
Jul 18 22:29:24 2016 <Lucifer_arma>	now, in a standard situation, that means that two out of three packets' worth of information is lost, unless they get resent when not acked
Jul 18 22:29:52 2016 <Lucifer_arma>	so, knowing that you'll increase the size of the packets, what if you, knowing this is the packet loss rate, go ahead and bundle, say, four messages in each packet?
Jul 18 22:31:08 2016 <Lucifer_arma>	then, two out of three can go missing, but the one that gets there has all the information for all three
Jul 18 22:31:38 2016 <Lucifer_arma>	the only serious issue I'm seeing (besides the potential for wasted bandwidth) is whether or not increasing the packet size to include 4x as many messages will also increase the overall packet loss
Jul 18 22:32:04 2016 <ct|kyle>	it probaboly will
Jul 18 22:32:40 2016 <Lucifer_arma>	badly enough to make it not worth it?  Like, at least linear?
Jul 18 22:33:16 2016 <ct|kyle>	that i'm not sure
Jul 18 22:33:31 2016 <Lucifer_arma>	I suppose it would have to be tested.  Maybe Z-man will know, heh.
Jul 18 22:33:58 2016 <ct|kyle>	(playing with wireless packets at work right now, trying to opitimize the data we send)
Jul 18 22:34:02 2016 <Lucifer_arma>	I'm not about to put that in my network game library, that's an "advanced" feature (assuming it even works) and I'm still working on managing connections in a basic way
Jul 18 22:34:24 2016 <Lucifer_arma>	well, you're probably in a good spot to try it, if it can be done reasonably easily
Jul 18 22:34:54 2016 <ct|kyle>	also how much extra procssing will be neede to filter out messages if you do get all packets?
Jul 18 22:35:06 2016 <ct|kyle>	or know what ones to keep
Jul 18 22:35:11 2016 <Lucifer_arma>	not much, really.
Jul 18 22:35:22 2016 <Lucifer_arma>	well, you give every packet an id, and if you've already received one, discard others.
Jul 18 22:36:10 2016 <Lucifer_arma>	you'd have to keep a window, of course, but a 5-10 second window isn't too bad.  You might keep a window as big as your timeout value.
Jul 18 22:36:14 2016 <ct|kyle>	I assume they are all fixed sized also, even if not, you can put the most recent first
Jul 18 22:36:19 2016 <Lucifer_arma>	efficient searches are the rule at that point
Jul 18 22:36:39 2016 <Lucifer_arma>	they don't have to be fixed size, either, but you'd need a way to delineate where one message ends and another begins.
Jul 18 22:37:22 2016 <Lucifer_arma>	using python, you'd make the first 4 bytes (or so) the type of the packet, and the second 4 bytes (or so) the size.  Then cut out the first message, parse it (google protocol buffers is quite fast), then move on to the next.
Jul 18 22:37:24 2016 <ct|kyle>	you just start them with a size of how long the message is
Jul 18 22:38:02 2016 <Lucifer_arma>	well, that's an aesthetic decision, to be honest.  Using protobuf, you still have to reserve bytes for the type of message so you can get the right class to use to parse it
Jul 18 22:38:03 2016 <ct|kyle>	(ya, almost exactly what we are doing at work :P
Jul 18 22:38:30 2016 <Lucifer_arma>	when you're packaging messages together, you'd make the first 4 bytes the message id
Jul 18 22:38:52 2016 <Lucifer_arma>	that way, when you receive one message id, and you've already processed a message with the same id, you can ignore others you might receive
Jul 18 22:39:25 2016 <Lucifer_arma>	one call to the struct module to parse out the packet id (I meant packet ID in that last two), then check to see if you've received it already
Jul 18 22:39:31 2016 <Lucifer_arma>	if so, continue.  If not, parse it.
Jul 18 22:39:55 2016 <ct|kyle>	ya
Jul 18 22:40:09 2016 <Lucifer_arma>	when you get the length of the section to parse, you subtract that from the length of the remaining buffer and construct a format string accordingly (I'm already doing that, so I hae handy code if you want it)
Jul 18 22:42:20 2016 <ct|kyle>	what I am doing at work is java code with a radio. Most of it is done, we've just gotten into optemizing it for what we are now doing with it
Jul 18 22:42:50 2016 <Lucifer_arma>	ah.  You're far ahead of where I'm at, heh.  ;)
Jul 18 22:43:16 2016 <Lucifer_arma>	I've just got the server pinging the client, the client acking, and the server tracking the status of the client, and making that somewhat reciprocal (the client pings every 2 seconds, the server every second)
Jul 18 22:43:45 2016 <Lucifer_arma>	and I'm using a shit-ton of bandwidth for no reason, indicating I'm not clearing one of my queues properly.  So I need to find that problem next.
Jul 18 22:43:51 2016 <ct|kyle>	ah, ya we have a whole app around it
Jul 18 22:44:30 2016 <Lucifer_arma>	I'm not quite near adding an app.  I have to solve my bandwidth problem, do a few minor things involving connection management, and start implementing the callback interface
Jul 18 22:44:50 2016 <Lucifer_arma>	when I have the callback interface started, then we can make a game client that can connect to a chat server, basically.
Jul 18 22:45:28 2016 <Lucifer_arma>	I'll make sure you can switch smoothly from lobby to game and back again, and disable lobby and drop straight into game, then start working on the game object hierarchy
Jul 18 22:45:41 2016 <Lucifer_arma>	the library should provide a base class that makes game object's available to be synced over the network
Jul 18 22:46:18 2016 <Lucifer_arma>	ideally, the game developer won't even have to think about the network beyond basic protocols needed to make the game work, which would be treated like any other events in an event-based setup
Jul 18 22:46:49 2016 <Lucifer_arma>	(I'll probably make a default pygame-based game client that just sticks network events in the sdl event queue)
Jul 18 23:03:59 2016 *	ct|kyle has quit (Remote host closed the connection)
View entire month
DISCLAIMER: These logs of public chat may contain some content which may not be appropriate for all audiences. Use at your own risk.
Logs from 2006-2009 pulled from wrtlprnft
Format changes at: 2015-08-25, 2017-02-20, and 2020-03-23. Times (2015 and later) should be Eastern.
. [About this site] [Credits]