1 msg 2 msg 3...lost

Networking and Multiplayer Programming

Started by KalvinB July 11, 2002 03:47 PM

81 comments, last by KalvinB 21 years, 9 months ago

142

July 12, 2002 08:43 PM

quote:Originally posted by KalvinB
That's great you're so educated in UDP and want to share this knowledge but I'm working with TCP/IP and am looking for TCP/IP solutions. All of my threads have been about TCP and you consistantly try to sell me on the benifits of UDP.

Ingrate. 251 words in my original post that went into great depth about why you have this problem with TCP. Not just a cheesey "here's how to fix it", but I went into detail of the root cause (nagling). 17 of those words added additional info comparing UDP. I gave you the TCP information, and in great detail. Yet you flame me for offering a wordy explanation that I guess wasted my valuable time to type in...
/sarcasm
Thanks. I feel thoroughly rebuked and sooo small now. You burned my eyebrows. AAAHHH!!! I'm burning! Melting... melting...
/sarcasm off

quote:
I'm perfectly aware when UDP is needed and when TCP will be sufficient. When I need help with UDP, I'll let you know.

KalvinB, when you illustrate a lack of understanding about fundamental TCP principles such as nagling, I doubt that you "perfectly" understand what is going on between TCP and UDP. That probably sounds harsh, but when I respond to questions here, I usually do so with the intent that you aren't the only person who will read it. I don't know the skill level of all the people that will read it. I try to provide complete explanations, and the hard truth of it is that a lot of inherent problems with TCP can be avoided by using UDP. If you are close-minded to that fact, I'm sorry. But don't flame people who offer detailed assistance on the forums. Forums are for discussion. That includes discussing alternative methods for accomplishing things.

editted to remove childish name calling... all apologies.

[edited by - fingh on July 12, 2002 11:05:54 PM]

a person

118

July 12, 2002 09:42 PM

kalvinB, your view is outnumbered. fingh and the others are absolutly correct. there is no garuntee a router wont combine packets, then another router possibly splitting them. there is no garuntee that your 50 byte messages will be sent as is. the OS will very well combine the messages (you saw that yourself). add some leatncey where packets may even take different routes thus arrive out of order to the TCP stack, and now there is a DEFINTE possiblity that things get split between calls. the split just has to be by one byte (ie one byte dont make it to a packet that is sent) and now your message is fubarred.

additionally the checksum used in TCP is not the most reliable system. it dont prevent malformation of the data section by a user messsing with data. since this is a game development forum it is a concern that the player may attempt to cheat by writing a simple proxy (ie like quake2 client side proxy bots).

try your app over a modem connection or other high latency low bandwidth channels. try your app across a router that drops random packets, etc. you will see how inefficent and possibly erorr prone (since you dont buffer) your method is.

i mean "Unless on the client side the last two messages are being combined in the recieve buffer as one message, but that shouldn''t happen." shows the misunderstanding you have of TCP in general. while you did finally realize that things were being done correctly by TCP and you were just doing things wrong, you must realize that you DONT understand TCP and UDP as will as you think.

KalvinB

102

Author

July 12, 2002 10:02 PM

fingh:

That's all fine and dandy but the point still stands that if I cared what UDP can do, I'd ask. I'm looking for TCP solutions and anything additional to that has zero relevance to this thread.

If you want to discuss the differences between TCP and UDP feel free to start a new thread or find a thread that is discussing the issue already.

"you must realize that you DONT understand TCP and UDP as will as you think."

Correct, but that doesn't change the fact I'm looking for TCP solutions. I know enough about UDP and TCP to know that TCP is what I'm going to be using for this project. If you don't agree with that decision then fine. But that doesn't change the fact that I'm looking for help on TCP.

"since this is a game development forum it is a concern that the player may attempt to cheat by writing a simple proxy"

What does any of that have to do with messages getting across and intact?

I had a very focused question for a reason. I solved the problem and now I'm moving on. If I have any questions about the benefits of UDP or how to stop hackers I'll start a new thread.

I appreciate the help (despite the fact I solved the problem well before anyone popped up with a solution), but badgering me about UDP is quite annoying.

As for packet spoofing; the server does everything. In fact, I'm designing the project to allow anyone to write a custom client. When the project goes public the source for my client will be made public. There are currently ~50 messages the server understands. I know how each of them works and how each of them can be abused. If someone figures out a way I didn't account for to prevent them from being abused, I'll deal with it then.

Again, if I have any questions about how to deal with hackers, I'll ask.

Unless someone has a better solution to my combined message problems then the one I came up with, this thread has served it's purpose.

Ben

IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

[edited by - KalvinB on July 12, 2002 11:19:20 PM]

[ IcarusIndie.com | recycledrussianbrides.com | Got Linux? ]

KalvinB

102

Author

July 12, 2002 10:13 PM

"The reason you are seeing complete transmissions is probably because you are doing your testing on a LAN or other very highspeed/low latency connection."

I am working on a 100mbit LAN so that could be. But at this point I''m just making sure all messages are getting across and the project works. At this point in the project it''s a very minor concern what happens in real world conditions with the Winsock portion of the code.

The "lost" packets became a concern at this point only because it was necessary that no packets were lost and it was affecting my ability to work on the rest of the project.

I''ll address the issue of partial packets when it becomes necessary. At this point in time I have a lot of other things higher on the list.

Ben

IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

[ IcarusIndie.com | recycledrussianbrides.com | Got Linux? ]

fingh

142

July 12, 2002 10:25 PM

quote:I appreciate the help (despite the fact I solved the problem well before anyone popped up with a solution), but badgering me about UDP is quite annoying.

Just for clarity, you have spent far more energy in this thread talking about UDP than all others combined. Just drop it. You keep mentioning it. I don''t get it... I gave you the full TCP explanation, yet you keep complaining that I made the mere mention of UDP? I think you are doing the badgering here.

And I''m sorry, but I''m not going to leave out information that someone else might find helpful just because YOU find it irrelevant. As I said before, I will give a complete answer/explanation when possible, including pros and cons of doing something. To flat out ignore other options is absolute ignorance (um, literally!).

In regards to answering your own question, well, you figured out how to get around the issue (great!), but you remained clueless to why it happened. So some of us tried to be helpful (in case others have similar problems). I''ve already apologized for being helpful, so I''ll refrain from grovelling.

I apologize for the name calling, it''s been corrected in the previous post.

KalvinB

102

Author

July 12, 2002 11:17 PM

Here''s the source for combining messages into one

  int a_winsock_server::SendData(message_handler data){	int returncode;	returncode = 0;	for(int y=0;y<data.numsend;y++)		if(data.to[y]<Max_Connections)			if (Client[data.to[y]].InUse == YES)			{				data.message.checksum=CheckSum(data.message);				data.message.to=data.to[y];				returncode = data.message.checksum;				memcpy(&Client[data.to[y]].buffer[Client[data.to[y]].bytetotal],&data.message, data.message.length+16);				Client[data.to[y]].bytetotal+=data.message.length+16;				if(Client[data.to[y]].bytetotal>768)					FlushData();			}			else				returncode = -2;	return returncode;}

.buffer is defined as char buffer[2048];

The check for 768 is just to make sure it''s not getting too big. You could take that out or raise the threshhold.

  void a_winsock_server::FlushData(){	int i;	for (i = 0; i < Max_Connections; i++)		if(Client[i].InUse==YES)			if(Client[i].bytetotal>0)			{				send(Client[i].ClientSocket, (char*)Client[i].buffer, Client[i].bytetotal, 0);				ZeroMemory(&Client[i].buffer,sizeof(Client[i].buffer));				Client[i].bytetotal=0;			}}

The client then handles the multiple messages per packet as of the modification posted earlier. No further changes were needed on that side.

The original Winsock Class I''m working off of is available here

Ben

IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

[ IcarusIndie.com | recycledrussianbrides.com | Got Linux? ]

a person

118

July 13, 2002 06:59 PM

"additionally the checksum used in TCP is not the most reliable system. it dont prevent malformation of the data section by a user messsing with data. since this is a game development forum it is a concern that the player may attempt to cheat by writing a simple proxy (ie like quake2 client side proxy bots)."

I NEVER suggested using UDP. heck i never even mentioned it beyond saying you dont understand the differences well (which you agree with)

dont be like a newspaper and use a partial quote out of context. i merely am saying just as the quoted section says. the TCP checksum is not the most reliable system for checking data integrity nor prevention of malformed packets via a proxy. being an open source client of course changes things a bit. now you may still want to checksum messages using an better system then TCPs simple method. thus helping to prevent some man in the middle attacks. thats up to you though.

though saying that dealing with "partial packets" (ie messages that "leak" between calls to recv()) is a low priority is just ignorent. if a client or server cant handle the most simple task or properly decoding the stream of data into the message packets, how can it accomplish anything else? i mean just a single "lost" message due to crossing bounds will mess up your players game (ie his input wont be registered). this will cause many problems.

i for one would DEFINATLY never play or use any app that cant even use TCP correctly to send data.

KalvinB

102

Author

July 13, 2002 08:19 PM

"though saying that dealing with "partial packets" (ie messages that "leak" between calls to recv()) is a low priority is just ignorent."

Um no. First of all, I frequent a TCP and forget it MUD with people from around the world (the server is in Canada) and I''ve yet to recieve a partial packet. I even wrote my own client so I know it''s not set up to handle it. The server doesn''t handle partial packets either. And oddly enough I''ve never had any problems or anyone else.

Second, at this point I more concerned that messages function properly. I''ve been fixing bugs for the last couple days.

Third, I''m working on getting the game rules in. I expect that to take at least another month.

And last, when I start testing it on-line, I''ll worry about partial packets.

"i for one would DEFINATLY never play or use any app that cant even use TCP correctly to send data."

The order at which I finish my project has absolutly nothing to do with that or being ignorant.

You''re just being dramatic.

Ben

IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

[ IcarusIndie.com | recycledrussianbrides.com | Got Linux? ]

a person

118

July 13, 2002 11:45 PM

you never been strike by lightening, but it is a possiblity, a slim and perhaps quite damaging one at that (ppl who got struck know that quite well).

basically just because it never happened dont mean it wont. ppl have downloaded files which were corrupt, then redownloaded the file from the same server and it was perfect. trust me, you dont want to deal with something as important as buffering late in the game. you will have plenty of other things to worry about. like the app not working on certain pcs, rules are not balanced, etc.

basically your being stubborn, i shall not suggest again. just be warned, someone using the app will expierence problems with "partial" packets and you will forget this maybe being the cause. once you do realize (if ever) you will note that it may require changing quite a bit of code depending on yoru design.

also i am not being dramatic, just truthful. if you would not bother to ensure your network code would handle such simple conditions, how can i be sure you handle malformed packets correctly? last thing i need is a buffer overflow exploit waiting to happen. or worse yet, get kicked for a malformed packet since your silly server ignored part of the message and now is using the end of the message as the start of a new message. ack, now everything is all screwy. oh well, i guess just reconnect and pray this random bug dont affect me again. yep, its the software everyone complains about, and you dont seem to mind introducing such bugs in yoru own apps. heh.

KalvinB

102

Author

July 14, 2002 12:01 AM

You''re being dramatic and it''s incredibly annoying and unnecessary.

Shut up.

I''ll deal with malformed packets when I get to it.

You don''t even know what my project is and you''re trying to tell me how to do it.

Ben

IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]

[ IcarusIndie.com | recycledrussianbrides.com | Got Linux? ]

1 msg 2 msg 3...lost

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

1 msg 2 msg 3...lost

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines