Kalvin, you are being very childish. You are kicking up a massive stink because you aren''t hearing what you want to here (getting your own way). YOU started this argument, simply because someone tried to provide you with a semi-detailed simplified reason why these things were happening, because this was something you obviously didn''t understand (from reading your posts) and it IS (contrary to your beliefs) important to understand the way TCP (or at least stream based sockets/connections) work if you want to develop a robust system using it. To be truthful, you''re being as pig-headed as kids who brag about their console being the best, even though they have never seen the specs or any sorts of benchmarks on any of the consoles.
Some words of advice:
"You''re being dramatic and it''s incredibly annoying and unnecessary."
I won''t touch the dramatic bit, but, if this thread is annoying, then just stop looking at it/replying to it!! Simple common sense there, no-one is forcing you to read or reply to this thread, at least as far as i know, no-one is pointing a gun at your head to do it anyway.
"Shut up."
Saying things like this really help to reinforce peoples views of you as being childish and stubborn.
"I''ll deal with malformed packets when I get to it."
Certainly this is your right, unless you are being employed to do it etc. then you can do it however you want. However, from my experience (and i''m sure many other people have had similar experiences), it is best to get your sub-systems in the best working order you can, and make them as robust as you can, before you develop much code that will rely on these sub-systems, as a bug in your sub-system could cause you to spend many hours looking for the bug in other code where it doesn''t exist, or you could end up writing code that works with the buggy sub-system, but as soon as you fix the bugs in your sub-system to get other code working, suddenly your previously written code breaks.
"You don''t even know what my project is and you''re trying to tell me how to do it."
I don''t believe anyone has truly told you how to do your project, several people, however, have pointed out that if your network subsystem cannot handle partial packets it will very likely have troubles once you move it off the saftey of your LAN and onto the real world of the internet. That is of course if you want to move your project onto the internet. (Sorry, it is very common these days, not many people create network multiplayer games exclusively for LAN anymore.) I don''t envy any employer you may have if you always take suggestions like this...
Anyway, enough of that.
I have a question for "a person". You talk about buffer overflows...this is only really a problem when working with UDP correct? If someone floods your connection or whatnot, with TCP this would not happen because it is controlled at a lower level than the application layer? Or where you talking about buffer overflowing more in relation to memory handling, rather than network specific problems?

Whatever anon. It''s not the suggestion I have a problem with. It''s the nagging and being overly dramatic about it.

Whether I deal with it today or tommorrow or next month it doesn''t matter.

"I don''t envy any employer you may have if you always take suggestions like this..."

And again, shut up.

If you want to have some intelligent advice go ahead. But this mindless berating you assholes are giving me for putting off your suggestion until my project needs it, is just obnoxious.

You people are going out of your way to attack me. If you can''t deal with the fact that some of your suggestions aren''t worth going into at this point then go away.

Ben


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

Lighten up Kalvin....You started the attacking..

No I didn''t.

Fingh took what I said as an insult but it wasn''t an insult. His comment on UDP was as appropriate in this thread as a comment on C++ is appropriate in a thread on Visual BASIC. If you can''t understand why that''s obnoxious then fine but don''t get on my case about it. That''s why I made the comments I did regarding it. I wasn''t insulting what he knew. I was just telling him this thread wasn''t the place for it which he should have known in the first place.

a person was the first with an attack calling me ignorant.

I called him dramatic because he is. And he''s obnoxious too going on an on about it even after I told him what my priorities were.

Why don''t you try actually reading the thread instead of glossing over it?

Ben


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

KalvinB, you are such a jerk.
The others are trying to help you and you just flame them.
Yes, I agree with the other post, that''s a very childish behaviour.

I didn''t flame the help.

People started flamming me when I told them their help wasn''t needed at this time.

I didn''t start the flames so if you want to bitch at people start somewhere else.

Ben


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

Anon. buffer overflows can happen in any message based system. basically if a message is sent and its fixed at x bytes, but the client/server could send x+1 bytes. now the client/server may properly handle this by making sure it checkes the values and makes sure they dont exceed the allocated buffers. some ppl dont bother with this. for instance they hardcode a 255 char buffer limit in there HTTP protocal parser. a malformed hearder of 300 could be sent. the stupid browser would continuly read bytes till it hit the carriage return. this overflowing the buffer. the smart browser would notice its at the end of teh buffer, and realize that the line length is too long. it could then either create another buffer for the rest of the data, truncate it and assume the data was not important thus not the next carriage return read will actually be part of the first one, or just trash the ocnnection telling the user a malformed request/response was recieved.

most buffer overflow exploits are a result of lazy coders who are too worried about getting things to work to "waste" their time checking for small details like not checking to make sure they read the data correctly, trusting the client (the worst thing), believing the internet wont break things and TCP is perefectly flawless. checksums do fail. clients may try to exploit your server by sending malformed packets. in fact the buffer overflow is the most used exploit since many times you can corrupt the stack and run arbitry code (though ussually limited in size) on the system.

kalvinB, i merely stated an observence that you agreed to. thus its not an attack, especially when you agreed with me. i may have been slightly dramatic, but even that does not seem to let you see that you are going about things wrong. i will no longer attempt to persuade you. if you dont want to listen to my expierence when creating client/server apps, thats your business. i just hope others that read understand the mistake you are making so others dont make the same ones.

do it your way. when it breaks you can waste the time going through the code. just dont expect to post the code and have ppl go through it and fix it later on if you wont listen to good advice now.

"but even that does not seem to let you see that you are going about things wrong"

You seem to have an issue with me working on it later as I told you I was going to do. The "problem" you think it has isn''t affecting my ability to work on the project which has bigger issues that need addressing unrelated to and unaffected by the Winsock portion of the code.

"i just hope others that read understand the mistake you are making"

What mistake? That I''m going to work on it later? OH NO!

"just dont expect to post the code and have ppl go through it and fix it later on"

I never post code for people to fix. I solve my own problems. That''s why I ask specific questions and expect specific answers when once in a great while I don''t know the answer. Turns out I did know the answer and I just jumped the gun posting.

"If you dont want to listen to my expierence when creating client/server apps"

One word: Relavence. If you had anything relavent to add, I''d be interested in hearing what you have to say.

Ben


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

quote:

---

One word: Relavence. If you had anything relavent to add, I''d be interested in hearing what you have to say.

---

Just because you don''t make the connection between inherent latencies of TCP and the widespread use of UDP doesn''t mean that my explanation of it is irrelevant. There is realy no reason for you (or aperson) to be so argumentative. I think someone could have learned from the first 4 or 5 posts, but now it has turned into a purposeless argument.

I never attacked or badgered you, I simply explained why you were having a problem. Yet you keep bringing my name back into this, and trashing the help I (and others) have tried to provide. Instead you keep arguing, which IS irrelevant to the thread, and to the forum (heck, to gamedev.net for that matter).

The question has been asked, answered and beaten to death. Any useful information that is going to come of this thread has already been put out, so let''s all move on, please.

KalvinB, I wish you luck in your project, however you decide to do it.

AP above is me, sorry for the multi-post...

[edited by - fingh on July 15, 2002 11:36:21 AM]