21 users logged in
Proud partner of GDC 2025
Before posting, review our community guidelines.
Support GameDev.net with a monthly GDNet+ subscription!
1 msg 2 msg 3...lost
122
July 15, 2002 03:52 PM
I hope nothing serious has happened to the moderator of this forum. I fear he might be lying dead in his bathtub at home or something
-------------Ban KalvinB !
July 15, 2002 03:54 PM
You''re a funny guy Granat. Why don''t you go Jump Off A Cliff?
Ben
IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]
Ben
IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]
122
July 15, 2002 04:49 PM
quote:
Original post by KalvinB
You''re a funny guy Granat. Why don''t you go Jump Off A Cliff?
Ben
Although I would say that this thread should have been closed (or abandoned) LONG ago, it most certainly should be closed now.
I''ve seen threads closed for comments much less rude than this one. You have the information you wanted, so why do you keep coming back to this thread?
And if you don''t see why this thread should be closed now, how about this?
Suggesting that somebody jump of a cliff is suggesting that someone kill themselves. Killing is one of the topics in
the FAQ says will generally be closed immediately.
I myself am hoping that the moderator is just busy doing something important.
--TheMuuj
--TheMuuj
July 15, 2002 05:43 PM
Apparently you''re new or don''t frequent the lounge.
"Go Jump Off the Cliff" is a perfectly reasonable thing to say to someone who''s just being a troll.
Another fun one is "may a cactus fall on you in the desert."
Ben
IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]
"Go Jump Off the Cliff" is a perfectly reasonable thing to say to someone who''s just being a troll.
Another fun one is "may a cactus fall on you in the desert."
Ben
IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]
122
July 15, 2002 07:18 PM
I thought Granat''s post was rather funny.
So will someone close this thread.
Dire Wolf
www.digitalfiends.com
So will someone close this thread.
Dire Wolf
www.digitalfiends.com
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
www.digitalfiends.com
118
July 16, 2002 01:01 AM
heh, this thread has turned into quite the pile of crap, yet shows how ppl dislike being wrong or being told what to do. great psyhcological stuff here.
fingh, you mention that both KalvinB and I stop being argumentive yet you do the same. I only did such things because like you fingh, I wanted to try to make KalvinB (and others reading the thread in case they sided with KalvinB) why its bad to do what he is doing (ie not handle partial packets and overall ignore how TCP works being stream based vs the message based UDP). many ppl think a single call to send() equates to a single packet and the mate call of recv() on the other side retrieves that packet intact.
its also seems to be a belief that you will never run across a partial "message" if you keep them under a certain size do to some TCP buffer size. let me tell you, that buffer size is not a requirment for the implementation. it wont fill up and then return data, it gives you the data it has up to the amount you request. i throughly explained that and wont delve into that again.
what some ppl on these message dont get is that you can easily just ignore certain advice, and go about your business. what you should not do is say that persons who is correctly answering, discussing, and overall being helpful to the query are wrong because you want to handle things another way. simply ignore the advice you dont care for and continue on yoru project. most ppl answer questions beyond what the poster asks because its helpful to others who read the posts and may be having the same problem. this is NOT your forum KalvinB, and just because you initiate a thread does not mean all posts relate to you only. some ppl actually search through the threads and do research.
KalvinB, its also not known what you do or do not know. you said AGREED with me that you did not understand the differences between TCP and UDP, thus anything you believe related to those topics could come from a misunderstanding you have stated you had. also, others reading the discuission may not know as much as you. its kinda of silly for you to expect us to know exactly what you understand and what you dont. i wrote quite a few network enabled apps that used varible sized messages over TCP/IP for comunication. so i know from expierence problems that arise. if you wish to ignore that, so be it.
another problem i notice is many posters not caring about the "why" of problems. why something goes wrong is what leads to finding a solution. using a solution without knowing why it works just leads to ignorence and code copying. without understanding how do you expect to generalize what you learn to other problems? for instance, if adding the delay solves the problem. great. however thats not a great solution. so you figure out why it happens. turns out TCP is stream based as you hoped it was not (ie confusing UDP and TCP). so you add code to parse the message in a buffer so the delay is not needed. you still are abit fuzzy why its correct. so we explain how TCP works and why certain things are the way they are. this should lead to you saying "ah ha" and coming up with a more error proof scheme that can handle oddities such as messages straddling your buffer bounderis (ie calls of recv()) which you have not expierenced since you have not tested things on the net yet where connections are not as perfect. also understanding the why will help you send the data more efficently since you see packing the data together for less calls of send() equals less overhead and possibly less bandwidth usage (depending how close the calls are, the OS or a router may combine them for you). less function overhead is also a good thing.
the understanding of TCP workings alos helps realize why send() (or recv()) may cause a pause if using blocking sockets. since by default the calls will wait for data. in the case of send(), the stack waits till there is room on the buffer for all your data, in the case of recv() it merely waits till there is at least a single byte in the stack buffer. this can cause stalls that are bad. worse yet, the recv may return with only a partial filled buffer so the bytes read that is returned is important. furthermore its even possible that send() could return early and not send the entire buffer (though most implementations send everything, some may not if you request to send a very large chunk) so the return value is important. heck the buffer may be too big thus and error code could be returned.
all those things need to be considered, as error checking is quite important o ensure things dont behave funny, crash, and then you cant find why it crashes. some ppl have "fixed" delete causing a crash by setting th pointer to NULL before calling delete. it fixed the crash, but it was still wrong since in realit the pointer was being deleted twice, and the coder failed to set the pointer to NULL after he deleted them. thus he tried freeing memory that was no longer allocated.
a small rant since i figure the thread went to crap already, maybe someone will find it funny with it closing with a silly discussion of how the Why of a problem is more important then an actual solution in order to learn and solve problems.
fingh, you mention that both KalvinB and I stop being argumentive yet you do the same. I only did such things because like you fingh, I wanted to try to make KalvinB (and others reading the thread in case they sided with KalvinB) why its bad to do what he is doing (ie not handle partial packets and overall ignore how TCP works being stream based vs the message based UDP). many ppl think a single call to send() equates to a single packet and the mate call of recv() on the other side retrieves that packet intact.
its also seems to be a belief that you will never run across a partial "message" if you keep them under a certain size do to some TCP buffer size. let me tell you, that buffer size is not a requirment for the implementation. it wont fill up and then return data, it gives you the data it has up to the amount you request. i throughly explained that and wont delve into that again.
what some ppl on these message dont get is that you can easily just ignore certain advice, and go about your business. what you should not do is say that persons who is correctly answering, discussing, and overall being helpful to the query are wrong because you want to handle things another way. simply ignore the advice you dont care for and continue on yoru project. most ppl answer questions beyond what the poster asks because its helpful to others who read the posts and may be having the same problem. this is NOT your forum KalvinB, and just because you initiate a thread does not mean all posts relate to you only. some ppl actually search through the threads and do research.
KalvinB, its also not known what you do or do not know. you said AGREED with me that you did not understand the differences between TCP and UDP, thus anything you believe related to those topics could come from a misunderstanding you have stated you had. also, others reading the discuission may not know as much as you. its kinda of silly for you to expect us to know exactly what you understand and what you dont. i wrote quite a few network enabled apps that used varible sized messages over TCP/IP for comunication. so i know from expierence problems that arise. if you wish to ignore that, so be it.
another problem i notice is many posters not caring about the "why" of problems. why something goes wrong is what leads to finding a solution. using a solution without knowing why it works just leads to ignorence and code copying. without understanding how do you expect to generalize what you learn to other problems? for instance, if adding the delay solves the problem. great. however thats not a great solution. so you figure out why it happens. turns out TCP is stream based as you hoped it was not (ie confusing UDP and TCP). so you add code to parse the message in a buffer so the delay is not needed. you still are abit fuzzy why its correct. so we explain how TCP works and why certain things are the way they are. this should lead to you saying "ah ha" and coming up with a more error proof scheme that can handle oddities such as messages straddling your buffer bounderis (ie calls of recv()) which you have not expierenced since you have not tested things on the net yet where connections are not as perfect. also understanding the why will help you send the data more efficently since you see packing the data together for less calls of send() equals less overhead and possibly less bandwidth usage (depending how close the calls are, the OS or a router may combine them for you). less function overhead is also a good thing.
the understanding of TCP workings alos helps realize why send() (or recv()) may cause a pause if using blocking sockets. since by default the calls will wait for data. in the case of send(), the stack waits till there is room on the buffer for all your data, in the case of recv() it merely waits till there is at least a single byte in the stack buffer. this can cause stalls that are bad. worse yet, the recv may return with only a partial filled buffer so the bytes read that is returned is important. furthermore its even possible that send() could return early and not send the entire buffer (though most implementations send everything, some may not if you request to send a very large chunk) so the return value is important. heck the buffer may be too big thus and error code could be returned.
all those things need to be considered, as error checking is quite important o ensure things dont behave funny, crash, and then you cant find why it crashes. some ppl have "fixed" delete causing a crash by setting th pointer to NULL before calling delete. it fixed the crash, but it was still wrong since in realit the pointer was being deleted twice, and the coder failed to set the pointer to NULL after he deleted them. thus he tried freeing memory that was no longer allocated.
a small rant since i figure the thread went to crap already, maybe someone will find it funny with it closing with a silly discussion of how the Why of a problem is more important then an actual solution in order to learn and solve problems.
July 16, 2002 01:48 AM
"you said AGREED with me that you did not understand the differences between TCP and UDP,"
When did that happen? I''ve never said that. Either your broadening what I said to try to make it sound like I understand less than I actually do (in which case you''re an idiot) or you''re making stuff up on purpose (in which case you should just go away because all credibility has just been lost).
Get off you''re little horse and sit down. Apparently you''re having a tough time accepting that your advice isn''t needed AT THIS TIME as I''ve said a number of times. If I had a question about partial packets I''d ask.
Nothing you''re saying has ANYTHING to do with this topic so why you''re still going on and on about partial packets is beyond me.
Find something else to do.
Ben
IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]
When did that happen? I''ve never said that. Either your broadening what I said to try to make it sound like I understand less than I actually do (in which case you''re an idiot) or you''re making stuff up on purpose (in which case you should just go away because all credibility has just been lost).
Get off you''re little horse and sit down. Apparently you''re having a tough time accepting that your advice isn''t needed AT THIS TIME as I''ve said a number of times. If I had a question about partial packets I''d ask.
Nothing you''re saying has ANYTHING to do with this topic so why you''re still going on and on about partial packets is beyond me.
Find something else to do.
Ben
IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com ]
122
July 16, 2002 03:08 AM
quote:
Original post by KalvinB
You''re a funny guy Granat. Why don''t you go Jump Off A Cliff?
I thought suicide was against your religion...? Maybe if you pushed me...No that would be murder and this is also not allowed by your religion (I think). Guess I have to stay where I am. Sorry....
-------------Ban KalvinB !
122
July 16, 2002 10:37 AM
quote:
Original post by granat
I thought suicide was against your religion...? Maybe if you pushed me...No that would be murder and this is also not allowed by your religion (I think). Guess I have to stay where I am. Sorry....
Oh let me...me...oh pick me...I''ll do it.
Hehe j/k.
Dire Wolf
www.digitalfiends.com
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
www.digitalfiends.com
142
July 16, 2002 12:07 PM
aPerson, I addressed you and Kalvin specifically, and I am pretty sure that I implied that I would also join in the non-argumentative future of this thread. Apparently not because people keep saying my name... ugh.
aPerson said what I have wanted to say all along... People don''t want to admit they don''t know how to do something, so they promote the easiest way around it.
But anyhow, this looks like a "last word" festival, so I''ll try to refrain from posting. Just leave me out of your future argument. e-mail me if you want to talk to/about me. thanks.
aPerson said what I have wanted to say all along... People don''t want to admit they don''t know how to do something, so they promote the easiest way around it.
But anyhow, this looks like a "last word" festival, so I''ll try to refrain from posting. Just leave me out of your future argument. e-mail me if you want to talk to/about me. thanks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement