quote:

---

If you don''t know how MUDs work then just don''t bother responding, k?

---

What MUD codebase are you referring to? I refer to DikuMUD and it''s common derivatives. I''d never play a mud that didn''t take my entire input. But hey, that''s just me. What is ''k''? Did you forget how to spell ''okay''?

quote:

---

It''s not a problem. Ask Pouya. It''s all in Fighn''s head. TCP packets aren''t the fragile pieces of glass he''d like to pretend they are. Text completion is a handy routine anyway. Again, ask Pouya.

---

Who is Pouya and why would I care? The name is Fingh, btw, please spell it correctly if you''re going try to flame me. And I never said anything about "TCP packets" because that nomenclature is complete ass-wipery. Please use direct quotes from my posts from now on if you''re going to use my name, because you continually misquote me.

quote:

---

"That sounds ineffective compared to having a header at the beginning of the message."

And yet MUDs never use a header because Telnet doesn''t support them smart guy.

---

And you still don''t understand what a protocol is... it really is laughable that you argue about things you don''t know about. MUDs use a header. It''s called ASCII. Typically (Diku, et. al.)the first space delimited string is the command type. Consider that ''command'' string your header. Just like with a binary encoded ''header'' you have to recv() until you have enough to use. This is a streaming issue, not a "packet" or "header" issue. And FYI, the MUDs I''ve played, coded, etc do NOT implement the telnet protocol, they use plain-jane TCP streams. The fact that telnet clients can be used to play is just part of how telnet works. Because telnet also uses a character-based protocol. Please, study, learn, then respond.

quote:

---

He and you are both a complete waste of time.

Are you done trolling and demonstrating your complete lack of any knowledge in this area?

---

Please quote references that discount the things I''ve said in regards to TCP and UDP. Some places to look would be Stevens, Comer, Jacobson, RFCs etc. Attacks are worthless(seriously, I don''t like to think about people laughing at your lack of demonstrated knowledge).

Post facts please, not drivel. User quotes rather than misquotes.

And yes, I just fed the troll.

"Now, a plain-Jane telnet client isn't going to know what to do with that header but hey, that isn't the point."

It's exactly the point.

"And you still don't understand what a protocol is..."

Obviously in the many on-line projects I've undertaken I've never developed a protocol. Ignorant troll.

"And yes, I just fed the troll."

I'm hardly a troll and you're just as irrelavent on these forums as ever.

"MUDs use a header. It's called ASCII. Typically (Diku, et. al.)the first space delimited string is the command type."

That's not really a header. It's just able to derive a "header" from what little information can be passed through a telnet capable connection which is text and escape codes. I use the same technique in my current project but I also use a real header because it's just immitating a talker to make testing easier. I also have more complex messages which both the client and the server use.

Pulling your head out of your ass and actually answering people's questions instead of going on and on about irrelavent BS like MUDs of all things which have absolutly nothing to do with the OP would be a step in a right direction. But I get the distinct impression from your history that you're just here to brag about all you know with a complete disregard for who you're talking to and what they actually need to know.

Pathetic. Until you learn to drop your ego you'll remain completely irrelavent on these boards. I solved my problems by activly ignoring everything you said because everything you said was worthless. And now this person is being helped just as little by you.

Nice trend. There's only one other person I've dealt with who's managed to be so irrelavent that problems were solved by doing nothing they said to do. Good job.

It takes real talent to not listen to people and just spit out irrelavent garbage and pretend you're actually helping them. Clue time: nobody gives a rats ass about little stupid symantics and "protocol" when the problem their having requires a very simple solution.

Lose the lecture teach. The students are too busy actually learning usful things and solving problems without your "help."

Ben



[edited by - KalvinB on February 27, 2003 9:12:25 PM]

For the record I've never criticized your knowledge of TCP or UDP. I've always criticized your distinct lack of ability to actually help people with that knowledge as you've so masterfully demonstrated yet again.

The fact you even claim I don't know what protocol is just demonstrates how out of touch you are with your audience.

You'll also notice I've never questioned you when you claim to have worked on major projects. That's just because IT'S IRRELAVENT. Interesting concept. "Relavency." Whether or not you actually worked on EverQuest or whatever* has absolutly nothing to do with your clear inablity to present what you know in any usable fashion that would actually benefit anyone.

Ben

*which I highly doubt as any sane person would do unless you could provide some actual proof. Hell, I worked on Carnivore!



[edited by - KalvinB on February 27, 2003 9:12:00 PM]

quote:

---

Original post by KalvinB
Pathetic. Until you learn to drop your ego you''ll remain completely irrelavent on these boards. I solved my problems by activly ignoring everything you said because everything you said was worthless. And now this person is being helped just as little by you.

Nice trend. There''s only one other person I''ve dealt with who''s managed to be so irrelavent that problems were solved by doing nothing they said to do. Good job.

It takes real talent to not listen to people and just spit out irrelavent garbage and pretend you''re actually helping them. Clue time: nobody gives a rats ass about little stupid symantics and "protocol" when the problem their having requires a very simple solution.

Lose the lecture teach. The students are too busy actually learning usful things and solving problems without your "help."

---

Anger leads to the dark side Darth Kalvin. All you need now is a silly black outfit and a lightsaber (or a lightflamer).

AntiVeggieBoy:

If I were you I would consider having a queue for incoming and outgoing packets (especially for outgoing). That way you are able to make the rest of your application more independant of the network layer. eg you won't have to check if the previous packet is send before your send a new one. Just make one Send_Packet() which add's a packet to your connections outgoing queue and worry no more :-).

KalvinB and fingh:

I don't get what you guys are arguing about?!? If you use TCP, you are not guaranteed that everything you ask for is send but send returns the number of bytes send and then it is just a matter of "keep calling send()" until the whole buffer is transmitted. if you implement packets on top of TCP and have a fixed size header.. you just keep reading until you get the header.. then you use the information in the header to retrieve the rest of the package.
The advantage of using TCP (even for packets) is that it is guaranteed that your packet will get send and in the right order (even though you sometime have to split it up because send returns a lower number than you expected).
The disadvantage is that the TCP protocol is implemented on top of UDP and the guaranteed delivery thing introduce overhead for applications which might not NEED it (say a game client which is spitting out position packets at a constant rate, if one is dropped - so what?). Use whatever gets the job done and it is not illegal to use both TCP and UDP in one application.

to me it sounds like you guys are arguing about who's the l33t'st motherf**cker :-)

to all:

I'm tired of State Machines :-).. almost everything you code today has to be a state machine.

btw. MUD's protocol is that everything send is ASCII (or ANSI). A protocol is an agreement between to applications about what the data they are sending eachother means.
The reason every string you type to a MUD server "makes it" all the way is that the telnet client is aware of the fact that send() sometimes does not send all the data you ask for it to send.

[edited by - Smokes on February 26, 2003 9:41:19 AM]

"I don't get what you guys are arguing about?!?"

His amazing ability to be irrelavent. Nothing annoys me more than people who can't just give a straight forward workable answer and instead choose to give information that doesn't answer the question or that just downright doesn't work and then insist on going on and on with their tangent.

"The reason every string you type to a MUD server "makes it" all the way is that the telnet client is aware of the fact that send() sometimes does not send all the data you ask for it to send."

No. The reason all the data gets to a client/server is because it's TCP. There's no header, just text and escape codes as defined by the telnet protocol. All the client does is put characters to the screen one at a time setting state flags as it hits escape characters to change the color of the text. It doesn't matter if it has the whole message.

The server on the other hand may buffer data until it gets the "\n" character or whatever the unix code for an endline is. MUDs tend to have a special character (such as . ) to define a command otherwise the message is just a plain text message.

But yeah, you're doing a fine job of explaining my point. A simple straight forward workable answer without the irrelavent BS.

Ben


[edited by - KalvinB on February 27, 2003 9:13:31 PM]

quote:

---

If you use TCP, you are not guaranteed that everything you ask for is send but send returns the number of bytes send and then it is just a matter of "keep calling send()" until the whole buffer is transmitted. if you implement packets on top of TCP and have a fixed size header.. you just keep reading until you get the header.. then you use the information in the header to retrieve the rest of the package.
The advantage of using TCP (even for packets) is that it is guaranteed that your packet will get send and in the right order (even though you sometime have to split it up because send returns a lower number than you expected).
The disadvantage is that the TCP protocol is implemented on top of UDP and the guaranteed delivery thing introduce overhead for applications which might not NEED it (say a game client which is spitting out position packets at a constant rate, if one is dropped - so what?). Use whatever gets the job done and it is not illegal to use both TCP and UDP in one application.

---

Actually, you don't have to call send() more than once unless you are purposefully fragmenting your data (i.e. to fit within the send buffer size). Otherwise, the entire buffer is passed to the kernel (and subsequently to the network stack) in the single call (depending on availability of space in your send buffer of course). You have to call recv() on the other side of the socket until you receive the all of the data you expected. Sometimes this takes more than one call, which is the basis of this thread. Also, TCP is not implemented on top of UDP, both are independently implemented on top of IP. Otherwise every frame would have a UDP header in addition to the TCP header. Not to be argumentative, but that seems to be another common misconception.

quote:

---

to me it sounds like you guys are arguing about who's the l33t'st motherf**cker :-)

---

I'm truly sorry to other posters/readers if it appears that way. I for one try to give complete answers or explanations in my posts. Some people appreciate the details, some apparently don't. I'm not going to dumb-down my responses here because one persons ego is too big for their depth of knowledge. I also try to correct presented misconceptions which is why KalvinB seems to think that I post off topic. I follow the discussion *gasp* of the current thread, which doesn't always follow the OP. If someone asks a question outside of the OP, it's acceptable to answer it within the thread that it's asked, since typically it's related in some way. Maybe we should have some Moderator input on that?

quote:

---

... or that just downright doesn't work and then insist on going on and on with their tangent.

---

Please quote something I posted that doesn't work.
I'm "going on and on" only in response to the fallacies that you promote here. The only thing irrelevant here is your weak personal attacks on people who give out information. Please, if you get annoyed, then stop "going on and on" about me in personal attacks and spend your efforts refuting the facts in my posts. Better yet, if I'm so irrelevant, don't respond at all. I don't post here for your specific benefit anyways.

quote:

---

Whether or not you actually worked on EverQuest

---

For the record, I don't believe I ever made such a claim. Most people working on high profile projects refrain from discussing specifics that might cost them their jobs. Yes, it's mostly irrelevant unless someone posts incorrect information about how that project works. And I would never claim credibility based on that particular project anyways.

Again, please use direct quotes in the future if you refer to me.

[edited by - fingh on February 26, 2003 2:45:26 PM]

[edited by - fingh on February 26, 2003 2:46:42 PM]

"I follow the discussion *gasp* of the current thread"

No you don't. You tried to turn my TCP thread into a UDP thread and you're doing the same here with no preemptive to do so.

"I also try to correct presented misconceptions which is why KalvinB seems to think that I post off topic."

No, you just sidetrack the thread based on your whims. There's no "seems" about it.

There's no "seems" about you consistantly failing to answer people's questions while babbling about everything NOT related to the question.

As someone pointed out earlier; you're as obnoxious as those people who tell others to use OpenGL when they ask a Direct3D question or visa versa.

Which is why you're irrelavent. You don't answer questions and you sidetrack threads. If you want to wow the world with your ability to quote the Winsock FAQ, start your own thread.

Ben



[edited by - KalvinB on February 27, 2003 9:13:58 PM]

quote:

---

No you don''t. You tried to turn my TCP thread into a UDP thread and you''re doing the same here with no preemptive to do so.

---

Actually go back and read this thread. You''re fixated on attacking me so you can''t remember that I mentioned UDP in response to someone elses direct post about UDP. Yep, in the other thread you started I mentioned UDP as an alternative. So sorry to offend you. Then you kept the thread alive with personal attacks. Charming

quote:

---

Which is why you''re irrelavent.

---

Another blatant personal attack. Please, find a new angle the attacks aren''t hurtful, they just reflect poorly on you.

I''m still not sure why you think discussion of streaming protocols is irrelevant to the OP. This discussion comes up often here, and it''s always the same root cause: the misconception of streams vs. datagrams. If you don''t see that, then you don''t understand the underlying issues. I can''t spell it out any plainer for you, and it''s obvious that I shouldn''t try because you don''t care. I''ll take my ''irrelevance'' back to work now.

"Yep, in the other thread you started I mentioned UDP as an alternative"

Which is as obnoxious as suggesting OpenGL as an "alternative" to D3D in a thread about D3D. If you can't see that then whatever.

"it's obvious that I shouldn't try because you don't care"

Problems solved without your help. So yeah, why would I care? If you can't see that nothing you say helps anything then feel free to continue wasting your time posting your long winded offtopic posts.

Ben



[edited by - KalvinB on February 27, 2003 9:14:16 PM]