Reasons Why Desync Happens (Thoroughly Explained /w Cited Commentary On Fixes & Focuses Info)

"

ScrotieMcB wrote:

"

gonzaw wrote:

Like, there should be a way to create a new protocol between the POE client and server to deal with most of this shit.

LOL no. These are internet protocols, not proprietary ones. You can't just invent your own internet protocol and have it work; it requires coordination across the entire internet, and programming in every router along the way. You're pretty much stuck with the existing methods of data transport.

But UDP/TCP are the transport protocols, I'm not saying you should reinvent those (not even IP)
EDIT: Yeah even if you reinvent a new transport protocol for GGG you don't need to change routers unless you want some ATM kind of shit

I'm talking about an application-level protocol, that would replace HTTP, and be more specific to GGG's needs (regarding sending packets, resending or not and analyzing what happens if packets are lost in UDP, or not in TCP, determining processes depending which packets the server gets or the client gets, etc).

"

ScrotieMcB wrote:

"

gonzaw wrote:

Does the POE server, 100% know whether a "POE packet" is legit or not?
Basically, when the server gets a POE packet, can he know 100% whether it was made legitimately by the POE client, or whether it's a fraud by some hacker trying to cheat?

I don't know all the nitty-gritty on this, but PoE uses encrypted communications. This means that spoofed packets would have to know how to encrypt the communication the exact same way the client would. This raises the bar to the point that botters prefer pixel-based detection (capturing data from the video card and analyzing pixels to determine the location of monsters and items) to network interception. And there's really no point in raising the bar higher than that, because PoE still needs to run on a variety of video cards, and it's the video card being compromised, not the communication.

It is worth pointing out that only the TCP transmissions would require encryption. UDP would be entirely server-to-client and thus wouldn't really require spoof prevention, unless Kripparrian gives out his IP address on stream or something stupid like that, and someone tries to man-in-the-middle his screen. So I guess it's possible, but I'm not really worried.

Oh okay, that helps then.
I don't really know the specific protocol between the client/server POE has though

You don't think client -> server should have UDP either at any point?

"

Lifendeath wrote:

This is a senseless, pointless thread. GGG have already explained why desync happens the cause of said desync and the possible solutions they are working on these kind of threads only serve as hyperbolic gathering points for 3rd party citations. You want to fix desync? do you live in Auckland? Otherwise 3rd party (fixes) really are senseless. But it's cure there's always a hero in every game w/ fixes to every solution. Oh, and i'll add unless you're not playing on your region gateway and have dial up connection desync isn't a problem.

It is not senseless! This Thread provides some reminder info for GGG regarding things they may not know about. This is why they rely on Beta Players because GGG's small team of developers don't know everything by themselves.

"

Lifendeath wrote:

You want to fix desync? do you live in Auckland?

Even if I did live very close to where GGG's Development Team is, and was capable of helping fix the Desync in-game, my good guess is the chance of getting accepted in are slim to none. Otherwise, yeah, I would love to be on their team to fix some issues.

I do have a little background knowledge in the C++ Code, etc. GGG uses for PoE.

"

Lifendeath wrote:

Oh, and i'll add unless you're not playing on your region gateway and have dial up connection desync isn't a problem.

This sounds backwards. It is the other way around in that if people are using Dial-Up Connection to play PoE or NOT playing on their own Region Gateway, that Desync is going to be a problem (not that it already isn't on GGG's end a player's computer and connection has nothing to do with.)

I mean, unless I'm missing something here I don't understand your logic.

P.S. Who the heck would use Dial-Up anyway to play PoE?

"

Lifendeath wrote:

This is a senseless, pointless thread. GGG have already explained why desync happens the cause of said desync and the possible solutions they are working on these kind of threads only serve as hyperbolic gathering points for 3rd party citations. You want to fix desync? do you live in auckland? Otherwise 3rd party (fixes) really are senseless. But it's cure there's always a hero in every game w/ fixes to every solution. Oh, and i'll add unless you're not playing on your region gateway and have dial up connection desync isn't a problem.

I play on my region gateway and I experience desync. I'm on broadband, not dial up. I hope you are trolling and don't actually think desync is purely a function of Internet connection. I'm a Software Engineer so I actually understand the technical side of what might be going on with PoE and its network / software / hardware architecture that has desync be the issue that it is - please don't trivialise it.

"

systemdown wrote:

I play on my region gateway and I experience desync. I'm on broadband, not dial up. I hope you are trolling and don't actually think desync is purely a function of Internet connection. I'm a Software Engineer so I actually understand the technical side of what might be going on with PoE and its network / software / hardware architecture that has desync be the issue that it is - please don't trivialise it.

It is definitely a troll. No one can be that illogical, then again, I often find myself taking those words back.

Hmm, okay, this may sound like an unrealistic solution (well it is) but it IS a solution for single-player games (an instance with just 1 player):

Analyze the average time it takes for a packet to reach the server from the client dynamically (most likely).
Add some variance to it, to determine the "threshold" you are willing to "wait" for a packet (just like TCP does basically, you can borrow that algorithm).

What do you do with this threshold? You keep in memory the full state of the combat/game/etc for that amount of time.
So if the threshold you get is 300ms, then you have, saved in memory, the state of the game from now until 300ms ago (every new "tick" of the game, you delete the last one, etc).

Now what happens when you (server) receive a new command (TCP) packet from the client?
Check the timestamp in it, and check your own timestamp.
After that, you rollback to the state NOW-(your time-client time), process the command, send back the UDP packet with the new stuff (damage done to monster, damage done to player, new position of the player/monster, loot dropped, etc)
After that set a new threshold (with the new difference in times you got from client/server), delete the states after the initial one, and keep going.

So let's tackle the usual problem:
There's a mob, and the client clicks the mob to attack it:

-Client clicks the mob
-Client sends packet "clicked position (x,y)" to server
-In client, the mob stood still, so the char got to the mob and was able to attack, he attacks it
-In server, time is passing so the mob moved away
-After X time, "click" packet arrives
-Server notices mob is too far away, only moves the char to that position
-Server tells client back "you just moved", no damage, nothing
-Client gets server packet, so the char just attacked the dude but nothing happened, and hell now his char in the server is actually in another position. Desync

How would this solve this?:

-Client and Server are in sync, server saves this state (let's call it initial state)
-Client clicks the mob in this "initial" state
-Client sends "clicked position (x,y) at time X" to server
-In client, the mob stood still, so the char got to the mob and was able to attack it
-In server, time is passing so the mob moves away. Server keeps saving new states every "game tick"
-After X time, packet arrives to server
-Server gets packet, calculates X time passed with the timestamps (local and from packet), server rollsback to that state X time ago (the "initial" state).
-In this state, the server sees the mob is actually near (and not far), so in the server the char goes to the mob, attacks it, and damages it.
-Server gives packet to client saying this
-After X time, client gets packet, sees "you did X damage to the monster", and shows the numbers and shit
-Client and server are in sync


But yeah, it may not be infallible at some other times (mostly because I don't know what info the server gives the client actually). The client may even need a similar "state saving" technique.
Also yeah this would most likely be costly and I dunno how it would work with more than 1 player in an instance.

But hey, it's a start at least right?

"

gonzaw wrote:

You don't think client -> server should have UDP either at any point?

The server is the one with the gamestate, the client is the one that needs the gamestate streamed to it. The client has nothing to stream that the server wants; just specific commands.

"

gonzaw wrote:

Now what happens when you (server) receive a new command (TCP) packet from the client?
Check the timestamp in it, and check your own timestamp.
After that, you rollback to the state NOW-(your time-client time), process the command, send back the UDP packet with the new stuff (damage done to monster, damage done to player, new position of the player/monster, loot dropped, etc)
After that set a new threshold (with the new difference in times you got from client/server), delete the states after the initial one, and keep going.

And now you are trusting the client to tell the server what time it is. Suddenly breaking GGG's encryption, as opposed to just going pixel-based, has an application. Hello, hacks.

"

ScrotieMcB wrote:

First things first: All UDP packets would have on them a simple timestamp (server time, since server is only UDP sender). All client calculations would pretty much start with "IF ThisTimestamp > LastTimestamp" -- so getting an out-of-order UDP packet wouldn't revert any gamestate, it would simply be discarded. Since we're not anticipating desyncs longer than a minute (timeout before that), a short that incremented each millisecond, looping back to zero after max, would do the trick.

The importance of the UDP protocol here is that we don't care about order here, we just care about the newest information, and the older information can be completely ignored -- hence no need for ordered delivery with the oldest packet always arriving first. (It also helps that lost packets won't be retransmitted, since they'd be moot by the time they got there anyway, and a waste of bandwidth.)

That said, TCP should be used for things like these:

• Player commands: User uses SkillA at position x,y
• Zone changes: entering entrances/exits, portals, waypoints, etc.; player is dead, character league transfers; login/logout, character selection
• Inventory: Unidentified unique Glorious Plate from ground to user inventory; Items X, Y, Z available at vendor; transfer Kaom's Heart from inventory to stash
• Character maximum/permanent stats: Max life, max mana, player's current level, XP to next level, passive point allocations, remaining refund points; name, class
• Party "permanent" stats: Name, class, level of party members; party member death; players leaving the party
• Simple idle/timeout detection

Many of these server-to-player TCP communications would require a client TCP acknowledgement; you don't want to start streaming UDP position data while the client doesn't know you've changed zones yet, or the client doesn't know it has a new party member.

Pretty much everything else -- everything that would fluctuate often during combat -- would be UDP:

• Current position: of player, of monster, of projectiles, of items on ground (only goes TCP once picked up); minimap info
• Character state: Life, ES, mana, XP
• Party info: % life, % ES, current position (including minimap)
• Monster/minion data: Monster type, facing direction, alive/corpse, white/magic/rare/unique, affixes
• Animation data: Identifier, position, current progess, end time
• Buff data: Curses, auras, charges, etc.; level of effect, time remaining

None of these would require a TCP acknowledgement, because newer UDP information is anticipated to be en route anyway.

I probably didn't cover all of them, because a bunch of minutae is involved, but the core concept is that if it doesn't change much, use TCP, and if it changes very often, use UDP. Note that some are kind of arguable; for example, you could argue sending the monster type, white/magic/rare/unique and affixes data TCP since it doesn't change much, but this might delay, then you'd need an ACK to start on the UDP, which might slow things down, so I opted to just resend it many times (this is why compactness is important).

i will start with a side note - the server must supervise any action by the client so the client must transfer all actions, in sequence, to the server, through TCP then. what we are talking about is a client transmitting via TCP. it is only the server that communicates some of the data through UDP. if i am wrong in interpreting your view, please explain. i see many holes in the server assuming a client can lose packets - opens a lot of room for the client to "fake" previous packets as lost.

as another side note, i don't know how the glorified calculators they sell today under the name of "router" would handle a UDP connection from outside (or even one initiated by the client, and same thing can be asked of the so called "firewalls"). can they even be set up to forward it? the more you make it user friendly, the less it is capable of. i honestly don't know the answer - been a long time since i even thought of UDP.

now to the question at hand. so basically, the client is transmitting everything via TCP (not really material to the point i am making), and the server constantly "shouts" everything to everybody in UDP. let me use a chess analogy, or, more specifically, the chess writing system. since the client doesn't acknowledge any packet, the server cannot assume anything was transmitted. so instead of having the board set up (changing it occasionally if we are to be true to the metaphor - as new mobs come, players join and leave, and so on and so forth), instead of being able to write each move on the next line, the server must write the entire set up on the board all over again - all items that are on the floor and their positions as one example.

is this what you propose? how do you plan to limit it? just transmitting the client's immediate surroundings on some radius, and once something is out of it, transmit via TCP? even so, holes on the minimap, for example, are bound to happen. maybe syncs with TCP every now and again?

and let us assume we have a perfect cooperation between UDP and TCP, with minimum redundancy (the sync with TCP for things out of radius is less important to the issue at hand, as the most important thing is transmitting all the current information to solve desync). even UDP'ing only what is on screen, constantly mentioning everybody in it and all that happens, will all this clutter (that is being constantly transmitted over and over again, even to just one player) be better than a TCP connection in the transmit-once format? in a lab maybe, but in the real world? <- honest question. do you have experience with such a thing online? will it work better?

"

"

Dao wrote:

i highly doubt GGG made a protocol similar to http. and i highly doubt that in the multiplayer gaming industry it is standard or common. but then again i am not a game designer.

In my experience, the emphasis is on debugging clarity, which leads to very human-readable data. It's rare to see a strong emphasis on compactness, and instead to see a focus on understanding how the client misinterpreted a received communication.

i don't see a contradiction. why can't it be transmitted as 1/0 and written on the developer's screen as "true"/"false" ? it won't break the debugging (unless your translator is bugged, but they are easy to write and easier to test). why would any sane man prefer to transmit text that you first need to generate in your program, then parse it again to extract the data on the other side? is the game data all stored in text as well? as i said, i highly doubt it. making just the debugging code translate the data is far easier, and agrees with both the major principles - logic, and laziness (had it been otherwise, usually laziness prevails over logic, but in this case they agree). but this is just my opinion, and as i mentioned, i am no professional. if you had experience with such things, your word has more weight in this, and i consider this matter settled.

"

"

Dao wrote:

any data transfer is in fact a sync attempt. and if the mobs are not moving, and neither is the player, it is not a combat situation, which means no sync attempts necessary.

However, players are moving in town -- even when the player playing the game isn't. Obviously we don't need update on that, nor on the player's progress from point A to point B after a command to move to point B, as much in town as we need it in non-town areas. We can send less packets and rely more on the client to predict player positioning.

if anybody complains about desync in town, it would be a matter to consider. but with all the UDP clutter i mentioned above, saving packets in town seems just useless. an (arguably) old Russian saying - saving money on matches and then wasting all of it on booze.

"

Nor do we need it as much when a player moves from point A to point B in a non-town area when not in any danger whatsoever. Which means you need some kind of monster proximity/quantity test to measure danger.

again, this is where the UDP-TCP sync would come into play, discussed above. UDP offers the speed you suggested, with the sacrifice of order and packet size. why save here at all if it is not the danger zone where you think UDP is needed? saving here won't make more room for later.

EDIT
TL;DR
i am not convinced that UDP (even in combination with TCP) is a valid solution to any real-time problem that requires data to be transferred from both sides and synced

"

ScrotieMcB wrote:

And now you are trusting the client to tell the server what time it is. Suddenly breaking GGG's encryption, as opposed to just going pixel-based, has an application. Hello, hacks.

A bad idea if the encryption is easy to break, sure. But let's say it wasn't - using some kind of strong RNG nonce scheme that was more or less impervious to man-in-the-middle forgery attempts?

Anyway, I'm not agreeing with this idea, but it could help the server ascertain just how badly pear shaped things went for the client and adjust accordingly, if its server-side cache of previous game states agrees with the client *shrugs*.

Of course, a cleaner and safer solution involves no transfer of game state from client to server.

EDIT: As for a contribution to this thread - knowing only what we know, I agree that UDP is a necessary part of the equation in addition to retaining TCP for the parts that require it. Not all packets from server to client need to have guaranteed arrival. The client can/should have some good interpolation/extrapolation heuristics going on that does a good job of rendering the most likely game state at any given time.

Also, I would not want to comment on things like packet compression and the backend server architecture used by PoE because from the outside, it's just a black box and we are not privy to the game code, nor have access to the infrastructure - no disrespect to any posters in this thread, but a lot of these proposed "solutions" are not based on any actual description of the real world problem (because we don't know what that is - the devs might not even know precisely why the sync mechanisms they already [surely] have in place are not yielding tolerable client-side results under load / latency stress). All we know is that UDP is not being utilised here, where arguably, it should be as a starting point. This will be a MAJOR re-write of the network code / event loop and I would think (hope) it's being worked on right now, because we might not see it for another 6 or 12 months (or more) before we even get to BETA test it.

IMHO - any "fixes" to desync whilst still on TCP I fear would just be papering over the cracks. Hopefully that is not so.. I really want to be wrong on this and somehow, PoE could be the ONE game of this type that gets away without using UDP. Fingers crossed.

"

Dao wrote:

Spoiler

i will start with a side note - the server must supervise any action by the client so the client must transfer all actions, in sequence, to the server, through TCP then. what we are talking about is a client transmitting via TCP. it is only the server that communicates some of the data through UDP. if i am wrong in interpreting your view, please explain. i see many holes in the server assuming a client can lose packets - opens a lot of room for the client to "fake" previous packets as lost.

Yep, sounds about right.

The only thing I'm not getting is the part where the client "faking" packets as lost opens up any room for hacks; I don't see how failure to acknowledge would open up hack opportunities, seems like the server would just log the client out eventually.

"

Dao wrote:

Spoiler

as another side note, i don't know how the glorified calculators they sell today under the name of "router" would handle a UDP connection from outside (or even one initiated by the client, and same thing can be asked of the so called "firewalls"). can they even be set up to forward it? the more you make it user friendly, the less it is capable of. i honestly don't know the answer - been a long time since i even thought of UDP.

UDP is required for RTSP, which YouTube uses to stream videos. Trust me, even the "calculators" have that shit down.

"

Dao wrote:

Spoiler

now to the question at hand. so basically, the client is transmitting everything via TCP (not really material to the point i am making), and the server constantly "shouts" everything to everybody in UDP. let me use a chess analogy, or, more specifically, the chess writing system. since the client doesn't acknowledge any packet, the server cannot assume anything was transmitted. so instead of having the board set up (changing it occasionally if we are to be true to the metaphor - as new mobs come, players join and leave, and so on and so forth), instead of being able to write each move on the next line, the server must write the entire set up on the board all over again - all items that are on the floor and their positions as one example.

is this what you propose? how do you plan to limit it? just transmitting the client's immediate surroundings on some radius, and once something is out of it, transmit via TCP? even so, holes on the minimap, for example, are bound to happen. maybe syncs with TCP every now and again?

Yes, that is what I propose. Don't really imagine limiting it too much, although common sense applies. If it's not on the screen or just outside it, it doesn't much matter, and we don't want the client having the whole map anyway, lest maphacks; the client can be trusted to store previously sent map data for opening up the map (not the minimap). Don't see the need for TCP when UDP should be pretty continuously incoming.

"

Dao wrote:

even UDP'ing only what is on screen, constantly mentioning everybody in it and all that happens, will all this clutter (that is being constantly transmitted over and over again, even to just one player) be better than a TCP connection in the transmit-once format?

You have a point that TCP, being reliable, has the luxury of only transmitting the things that change; UDP has to transmit everything every time. However, you also have to keep in mind that the client can use last known info, and that a lot of things are prone to change so often that their default state is change, and thus TCP holds no advantage.

Think of the things that change in combat continuously. Life, ES, mana, positioning, spell animations, attack animations, facing. Items dropping, being allocated to someone else, then not being there anymore. Clearly UDP.

Think of the things that almost never change in combat. Max life, max ES, max mana, everything else on your character sheet, your inventory (you're not dropping items much). Clearly TCP.

I'll admit there are some border cases. Like trees, streams... pretty much everything in the map which doesn't move. You shouldn't send the whole map at once, or you're trusting the client with the far edges of the map, increasing maphack vulnerability; you should send the client little bits at a time, which is like streaming, which implies UDP. But those bits don't change, which implies TCP. I'm leaning UDP, but you can make arguments either way here.

"

Dao wrote:

do you have experience with such a thing online? will it work better?

"

Dao wrote:

Spoiler

"

"

i highly doubt GGG made a protocol similar to http. and i highly doubt that in the multiplayer gaming industry it is standard or common. but then again i am not a game designer.

In my experience, the emphasis is on debugging clarity, which leads to very human-readable data. It's rare to see a strong emphasis on compactness, and instead to see a focus on understanding how the client misinterpreted a received communication.

i don't see a contradiction. why can't it be transmitted as 1/0 and written on the developer's screen as "true"/"false" ? it won't break the debugging (unless your translator is bugged, but they are easy to write and easier to test).

Notepad is a pretty cheap pre-made translator, which is good. Kind of lacks features though.

"

systemdown wrote:

Spoiler

"

ScrotieMcB wrote:

And now you are trusting the client to tell the server what time it is. Suddenly breaking GGG's encryption, as opposed to just going pixel-based, has an application. Hello, hacks.

A bad idea if the encryption is easy to break, sure. But let's say it wasn't - using some kind of strong RNG nonce scheme that was more or less impervious to man-in-the-middle forgery attempts?

Anyway, I'm not agreeing with this idea, but it could help the server ascertain just how badly pear shaped things went for the client and adjust accordingly, if its server-side cache of previous game states agrees with the client *shrugs*.

The other problem with this is you're essentially asking the server to store many instances where it previously stored only one. If you didn't know, the reason why town portals close if you AFK too long is because the servers don't have the resources to have so many instances up simultaneously, so the server closes them and the portals that go to them. Say hello to 2-minute portals.

But let's say that doesn't happen because GGG not only finds the money to properly redo netcode for UDP, but also lots of nice new servers. Let's say someone's at the top of the Onslaught ladder, and they die. Normally, the server would send information to the client to display the "You have died" screen, move the character to Standard, and mark "Dead" by their name on the website ladder. But wait! 762 milliseconds after the death was declared, the server gets a command from the player, dated 788 milliseconds ago, to hop in a Town Portal he created. So the server does one of two things:

• completes death actions immediately upon death, then implements undo commands to clear out the "you have died" screen, move characters from Standard to Default league, and remove Dead status from ladder rankings. In addition to being potentially exploitable commands, this opens up a whole can of worms as people realize that GGG has a command to resurrect dead hardcore characters.
• implements a waiting period before implementing certain responses, to see if a delayed command appears. This is kind of a slippery slope, and if GGG goes all the way down it, the delay before responding to anything you do would be about equal to the acceptable delay in your actions... which means you'd both be living an equal amount of time in the past, having zero effect for a shitload of coding. The less important it is (lack of death, lack of awesome item, etc.) the more likely it is not to suffer mutual delay, which runs counter to what we want the suggestion to do.

All in all, a lot of work for something that's desync treatment, not desync prevention.

"

ScrotieMcB wrote:

The only thing I'm not getting is the part where the client "faking" packets as lost opens up any room for hacks; I don't see how failure to acknowledge would open up hack opportunities, seems like the server would just log the client out eventually.

you just illustrated a case of it in your response to systemdown.

"

Yes, that is what I propose. Don't really imagine limiting it too much, although common sense applies. If it's not on the screen or just outside it, it doesn't much matter, and we don't want the client having the whole map anyway, lest maphacks; the client can be trusted to store previously sent map data for opening up the map (not the minimap). Don't see the need for TCP when UDP should be pretty continuously incoming.

already mentioned maphacks in the first post. what i meant was something along the lines of "all known data at this time", which is why i suggested limiting to on screen or in some radius.

"

Spoiler

You have a point that TCP, being reliable, has the luxury of only transmitting the things that change; UDP has to transmit everything every time. However, you also have to keep in mind that the client can use last known info, and that a lot of things are prone to change so often that their default state is change, and thus TCP holds no advantage.

Think of the things that change in combat continuously. Life, ES, mana, positioning, spell animations, attack animations, facing. Items dropping, being allocated to someone else, then not being there anymore. Clearly UDP.

Think of the things that almost never change in combat. Max life, max ES, max mana, everything else on your character sheet, your inventory (you're not dropping items much). Clearly TCP.

I'll admit there are some border cases. Like trees, streams... pretty much everything in the map which doesn't move. You shouldn't send the whole map at once, or you're trusting the client with the far edges of the map, increasing maphack vulnerability; you should send the client little bits at a time, which is like streaming, which implies UDP. But those bits don't change, which implies TCP. I'm leaning UDP, but you can make arguments either way here.

i got interesed, used google for a quick peek, and apparently, ARPGs tend to use UDP in some cases. for first person shooters it is a must, for real time strategy it is TCP all the way, and ARPGs are hanging on the fence, at least that's the impression i got right now, leaning towards using UDP.

but in the hits i got on google, they use UDP's strengths and mitigate the weaknesses - writing a reliable (though less than TCP) protocol over it, thus making it a compromise of both. it is not pure UDP as you present it, which would reduce the problems i am talking about, and make it quite workable, and in the cases you mentioned preferable.

"

Spoiler

What I did do was work communications in the US Army, helpdesk-style, for over three years. For the most part that consisted of carrying a rifle, crimping CAT5 cable, telling officers where to click in Outlook, heat, sand, and push-ups. I'm not really a programmer; my highest accomplishment is probably a .bat file I wrote in Notepad that produced the angriest ping sweep imaginable (with text file output). I'm not really a network expert; I have successfully configured a switch before, console cable and all, but I'm afraid I forgot how. However, I did get a chance to work side-by-side with a lot of really, really smart people, which means I picked up a lot of eclectic IT knowledge. I also discovered that I am the communications version of MacGyver; I made a functioning satellite transceiver cable adapter out of paper clips and duct tape, plus the whole "internet's down, can't figure it out, get me a ping sweeper," "hold on, let me fire up Notepad" thing.

That said, I'm by no means classically trained, and my inner lawyer told me to say that anything I say in this thread is not offered as and does not constitute professional advice or professional opinions.

i played with x86 assembly and C in the distant past, amateur stuff. even learned some ARM assembly a little. did get to examine low level things, had an RFC phase where i learned all of the relevant protocols, and even skimmed through their implementations in publicly available code. wrote some network related things, workable in some cases. nothing fancy. most notable would be an IRC client in pure assembly, another was some C project that did fancy stuff with other protocols. i played with raw sockets a little bit, constructing my own packets. was interested in security, and have an understanding (though basic, especially considering the time that passed) in what needs to be secure and what can be breached. no game programming experience, especially something that requires this much real time and synchronization. no knowledgeable people to consult with, though i do study well on my own (at least the theoretical parts of most subjects). most of my knowledge base is out of date (though a lot of basic things didn't change, but many things changed and evolved quite a bit). i played with UDP too on a very basic level - learned how a name server is written, and through it how the protocol is used. seems UDP is much more popular these days.

"

Notepad is a pretty cheap pre-made translator, which is good. Kind of lacks features though.

this is where we still don't agree. i will ask again - why would you take the data in your program, convert it into readable text, and send it over the wire, just to have it parsed and translated back into data? what advantage is it to debugging? the data is not stored as text in the program. you write in plenty of debug code that spews text at you, translates your data into readable form, but why also make it go over the wire like that? you can make the debug output the data on both sides, before sending, and right after receiving. i see no advantage to converting it there and back, especially since those are two different pieces of code, while converting it twice to text, once on each side, is the same code, so less coding for the lazy programmer (and being lazy is a requirement, so your code can be nice and modular and not redundant). i will not believe that somebody makes lots of text go over the wire, working on a real time networking project no less, until i see it with my own eyes.