Log from 2016-07-19:
Jul 19 00:36:07 2016 <Lucifer_arma> why is my while loop executing its body even when the statement evaluates to false?
Jul 19 03:42:53 2016 <wrtlprnft> Lucifer_arma: generally, unless your setup is completely broken, I would assume that the only reason for frequent packet losses is that you're using too much bandwidth
Jul 19 03:44:06 2016 <wrtlprnft> TCP does rate limiting based on this assumption
Jul 19 03:45:53 2016 <wrtlprnft> Packet losses due to checksum mismatches and the like should be extremely rare, at least on wired connections
Jul 19 03:47:00 2016 <wrtlprnft> And wifi does its own forward error correction and re-sending thing, even with UDP packets
Jul 19 03:49:51 2016 <wrtlprnft> Maybe increasing your data rate coud help in a situation where the bottleneck is shared with other people's connections, so by sending more data, more of their packets get lost, but that would be a dick move :-)
Jul 19 03:51:36 2016 <wrtlprnft> And I doubt that it would work for anything beyond maybe your home router
Jul 19 04:13:32 2016 <Lucifer_arma> Interesting. ;)
Jul 19 04:14:05 2016 <Lucifer_arma> On a different note, my 12yo is interested in programming, so I showed him the most important lines in any program you ever write. He lost interest.
Jul 19 04:14:10 2016 <Lucifer_arma> It was too much legalese.
Jul 19 04:14:24 2016 <Lucifer_arma> It was obviously the GPL headers you put at the beginning of a program.
Jul 19 04:49:04 2016 <wrtlprnft> I hate those
Jul 19 05:10:59 2016 <Z-Man> Lucifer_arma: yes, there are situations with a high intrinsic packet loss. TV cable connections were notorious. In these situations, if timing is critical, it's beneficial to resend messages before you know they were lost.
Jul 19 05:11:42 2016 <Z-Man> X-Wing vs Tie Fighter categorically sent the two last messages with each packet, so each message got sent twice.
Jul 19 05:12:31 2016 <Z-Man> It was especially important for them because they used the strategy game network model: The messages contained only client input data and each client ran an independent simulation based on that input.
Jul 19 05:12:52 2016 <Z-Man> So to get the current gamestate right, you needed ALL of the previous messages.
Jul 19 05:13:11 2016 * Z-Man read their postmortem on Gamasutra
Jul 19 06:12:43 2016 <wrtlprnft> Doesn't TCP break completely with high packet loss?
Jul 19 06:13:29 2016 <wrtlprnft> Of course it depends on what you consider to be high
Jul 19 10:31:55 2016 * ljrbot has quit (Max SendQ exceeded)
Jul 19 10:35:35 2016 * ljrbot (~supybot-l@2001:470:88ff:2e::1) has joined #armagetron
Jul 19 10:57:43 2016 <Z-Man> wrtlprnft: yeah, it can break completely. I don't think it could handle the 66% packet loss of Lucifer's scenario. When on bad wifi, I've seen lost TCP connections more often than I've seen the wifi connection drop completely. But under not totally crap conditions, connections stay up, datarates just go way down.
Jul 19 11:10:06 2016 <wrtlprnft> Well, I suppise that for a randomly lost packet every couple of seconds, a TCP connection would suffer a bit, but for a game, it would probably be more annoying
Jul 19 16:16:56 2016 * G5 (~g5@p2003006A6A7BA200945EFADEAD3BC08F.dip0.t-ipconnect.de) has joined #armagetron
Jul 19 16:43:56 2016 * G5 has quit ()
Jul 19 16:49:39 2016 * G5 (~g5@p2003006A6A7BA2004CA13C3F26FE8016.dip0.t-ipconnect.de) has joined #armagetron
Jul 19 17:37:00 2016 * ct|kyle (~email@example.com) has joined #armagetron
Jul 19 18:07:10 2016 * G5 has quit ()
Jul 19 18:08:45 2016 <Lucifer_arma> freeciv uses tcp for its network layer, and it's downright shitty. When one player gets blocked for any reason, like their connection timing out, all players get blocked because the server blocks on that one person.
Jul 19 18:09:24 2016 <Lucifer_arma> for that reason, even when I add file transfers to my game library, it's going to use udp for everything. I figure game data doesn't have the high reliability requirement that tcp satisfies, so there's no reason any game should ever use tcp.
Jul 19 18:10:10 2016 <Lucifer_arma> now, for game data that does have that high reliability requirement (like file transfers), I have every intention of including the appropriate error checking and packet resending.
Jul 19 18:11:40 2016 <Lucifer_arma> I like the idea of automatically resending the last packet with the current one (excepting pings and acks, of course)
Jul 19 18:12:12 2016 <Lucifer_arma> the added redundancy would increase overall reliability without significantly impacting bandwidth usage (probably only increase bandwidth usage by 50% or so, since pings and acks are excepted)
Jul 19 18:22:49 2016 <Lucifer_arma> also, using udp, it's worth taking a page from bittorrent. With tcp file transfers, if you're waiting for a packet, it doesn't matter how many of the packets after it you've received, you still block on the socket read waiting for that one packet
Jul 19 18:23:24 2016 <Lucifer_arma> with udp, taking a page from bittorrent (which uses udp), for file transfers you can simply store the packets and link them in the proper order when you have enough file information to do so
Jul 19 18:24:19 2016 <Lucifer_arma> if you also track which packets you've missed, then in the event you timeout from the server before the file is completely transferred, when you reconnect you can tell the server which packets you've already received and it only has to send the ones you don't have.
Jul 19 18:25:06 2016 * Lucifer_arma has always wanted arma to do its own file transfers, server to clients
Jul 19 18:57:48 2016 <Lucifer_arma> while len(self.__incoming) > 0: <--- that means when the list self.__incoming is empty, the while loop should stop executing, right?
Jul 19 19:42:59 2016 * Lucifer_arma has quit (Remote host closed the connection)
Jul 19 19:52:47 2016 * Lucifer_arma (~Lucifer_a@cpe-66-68-59-243.austin.res.rr.com) has joined #armagetron
Jul 19 20:09:38 2016 * guru3 (~firstname.lastname@example.org) has joined #armagetron
Jul 19 20:11:40 2016 * guru3_ has quit (Ping timeout: 252 seconds)
Jul 19 21:52:53 2016 * zmanuel (~Z-Man@p4FC16A4E.dip0.t-ipconnect.de) has joined #armagetron
Jul 19 21:52:54 2016 * Z-Man is now known as Guest84889
Jul 19 21:52:54 2016 * Guest84889 has quit (Killed (sinisalo.freenode.net (Nickname regained by services)))
Jul 19 21:52:54 2016 * zmanuel is now known as Z-Man
Jul 19 22:55:36 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.