Single characters returned by recv

Started by
6 comments, last by rck 16 years, 4 months ago
So I'm attempting to write a mud server application and I'm experiencing oddities with the recv function. In the server I have a loop that processes the recv function until I disconnect. Every time data is received I send it back to the client, to make sure that the server is receiving the data. When I connect in via telnet or putty, it's sending the data (and as a result the server app is echoing it back out) every keypress. I saw another topic on these boards about someone trying to parse the recv data on /r/n and the consensus was to just buffer the input and scan it for that character. Since I'm going to be processing potentially hundreds of connections at once (realistically less, but let me think my stuff could get popular) that seems like it could get pretty memory intensive real quick. It also seems like I would have to process the special characters like backspace, etc. to make text input not suck. So my question is this: Is there a way to make the recv function wait until it receives a certain character? Or are all the other mud servers out there handling the text input and buffering everything? Here's the code I'm using to handle the recv function. int intResults; char bufRecv[256]; do { intResults = recv(tmpSock, bufRecv, 256, 0); send(tmpSock, bufRecv, intResults, 0); } while (intResults > 0);
Advertisement
Quote:Original post by hellempyreal
So I'm attempting to write a mud server application and I'm experiencing oddities with the recv function.
...
I saw another topic on these boards about someone trying to parse the recv data on /r/n and the consensus was to just buffer the input and scan it for that character. Since I'm going to be processing potentially hundreds of connections at once (realistically less, but let me think my stuff could get popular) that seems like it could get pretty memory intensive real quick.


Not unless you're hosting it on a Commodore 64.

How long do you expect a typed line of commands to be? Let's say 10,000 letters. How many connections do you expect? You say hundreds - let's say 999, otherwise you'd have said a thousand.

Memory use = 10000 x 999 = just under 10 megabytes. That's barely anything by modern standards. Don't prematurely optimise.

Quote:It also seems like I would have to process the special characters like backspace, etc. to make text input not suck.


That's right. It's actually quite complex when you layer the telnet protocol, ANSI colour codes, backspaces, MUD-specific out-of-band data, etc.

Quote:So my question is this: Is there a way to make the recv function wait until it receives a certain character?


No. You could wrap it up in something that makes it look like a stream or a file, and read to the delimiter, but that just gives you all sorts of other problems to contend with. (What if the character is escaped? What if the character appears in the middle of a Telnet command sequence and therefore doesn't delimit anything?)

Quote:Or are all the other mud servers out there handling the text input and buffering everything?


Yes.
Quote:Original post by KylotanNot unless you're hosting it on a Commodore 64.


Even then it's not really a problem.
Ok. If that's what has to be done, not a big deal. I just didn't want to start coding all of the manual handling of everything only to realize a month later that there was a function that already did it.

As far as the memory is concerned, I realize it's not that much, but I didn't want to bloat unnecessarily.

Thanks for the prompt replies.
There are functions that already do that. There are so many open source MUDs you can't count them. You could just get the code from one of them, and be on your way. It'd be a lot quicker than writing it yourself.

Also, if you're on UNIX/Linux, you already have code that does it in the TTY/PTY driver and the readline() library. You could have a very simple shell application that gets forked when a user connects, which reads a line, then passes it on to a central MUD server application that only knows how to talk to those line-reading processes (using pipes, or whatever).

If all you want to do is avoid writing code, then there are tons of ways of solving that problem.
enum Bool { True, False, FileNotFound };
I'm not trying to avoid writing code (I'm doing this more as a learning experience than anything), I'm trying to avoid writing code unnecessarily. There's no point in trying to write base level code if a standard function already exists for it (that would be like trying to write your own 3d engine using trig, when you can just use DirectX). I started toying with different options to make the delete key work, and it was acting crazy and weird on both clients I was using to test (Putty and windows telnet).

I went and downloaded the source for Tiny MUD. From I could see it wasn't doing any sort of custom processing of any characters. Unfortunately I was unable to compile it and get it running so I don't know if it has the same quirks or not.

But I just found a couple articles on mud creation in the articles section, so I'm going to check those out and see if they address any of this.

Again thanks for all the help.
When you receive a delete key (127 or 8, typically), you should send 8 32 8 in response. This moves the cursor backwards, then replaces the character with a space, then moves the cursor backwards again.
enum Bool { True, False, FileNotFound };
Only scan the input buffers when the buffers are updated (eg, receive new data).

This topic is closed to new replies.

Advertisement