Programming

Code:

getconf OPEN_MAX
256

will show you how many file one process can have open at one time (don't forget three for stdin, stdout, stderr).

In the example above you have 253 available file slots. In C you can call getdtablesize() (unistd.h) to see what the limit is, it may NOT be OPEN_MAX. It probably is more.

Ok thankyou.

---------- Post updated at 05:31 PM ---------- Previous update was at 05:21 PM ----------

Thanks neutronscott. While you still have the program handy could you maybe help me with an overflow problem. When I receive with my two functions create_character, and character_login. Well when I receive data that is longer then recv is receiving It seems to recv again three or four times depending on the amount of characters over the limit there are. I was hoping you could shine some light on this subject so I can try to fix it myself maybe even post some more snippets. I had the idea that if you sent one thousand characters I would only receive 12 and that would be the end of it. Should I FD_CLR and then FD_SET after a receive and if so how to I send a fd_set to a function?

It's like a file. If you read 30 bytes from a 100 byte file, there's still 90 bytes to go. If you don't know how long it is, you have to keep reading until you find the end.

Except it's a file that arrives whenever it feels like it, in chunks of whatever variable size it feels like. If you don't know how long a field's supposed to be, the socket can't tell you. Not dependably, anyway. It might arrive in the size it was sent in -- or the socket might decide to wait and send it all in one big 64K chunk. You can't guess.

Your protocol should include some sort of terminator for variable-length things, since you can't guess from how much you read.

what do you mean terminator? how do you tell recv to only recv 12 bytes and only 12 bytes from a single send regardless of the amount of data they sent? Is it possible to recv in that manor?

I noticed that too. In my trials to learn such things each client had their own buffer and also an int or ptr into where it's at, since you're not guaranteed to get the entire line in 1 read (unless you wrote the client too). I appended into it until a newline. If the clients buffer was full, my read loop would just discard the extra data between buffer size and newline. Then attempt to process it all. Then reset the buffer.

I think all your FD_SET/FD_CLR stuff is OK. In mine, I FD_ZERO at the top of the loop and then FD_SET my listener, and iterated over my linked list and FD_SET those. Yours is more efficient.

Send the string with a \n on the end. So when you see the \n, you know you've received the entire thing. Once you have, just chop off the front of it and put it in your structure, ignoring the rest.

If they send 1000 bytes, you get 1000 bytes.

Yea but i want to receive from mush clients. I haven't planned on making a client for the program so I was hoping you could tell me how to receive only 12 bytes and ignore the rest. If you can't I might just make a linked list buffer. Also you wouldn't happen to know why if I receive data, why when I receive 15 bytes the program decides to recv 12 bytes then one byte at a time would you? Maybe neutronscott could help me with this just cause hes been working with the program. Any light on this subject would be awesome also.