-
Question about recv
I have a couple of questions about socket programming that have to do with recv.
I know there is a way to peek at data before it comes in by some flag or something, but should I always just make a buffer with a decent size so that I don't need to worry about it?
Also, many of my programs after they receive something trigger a send. Is it needed to send on it's own thread so that if data comes in recv won't miss it?
Really what it comes down to is that I don't know exactly how recv works. Will data just pile up until I read it through recv? I don't know if data is lost if you don't recv it immediately.
-
I don't think you can lose data in the input queue of a socket this easy (if at all).
Every time you call recv it will take the next chunk in line. You can do whatever you want next (send, etc.), the incoming stuff will just wait. It could be that the input queue does have some kind of limit if you let your connections send in a continuous stream for five or ten minutes at 5mb/sec without trying to read from them. But if you are actually checking those connections at all I would not worry about it, even just every few seconds will be fine (which is plenty of time to do just about anything you might want to do). You don't have to have recv() ready and waiting when a send() comes in, if that's what you're thinking.
Incidentally, the buffer and buffer size used by recv have nothing to do with this input queue. That's just the buffer that stuff gets put into by recv. As long as the buffer is as big as you say it is, it's fine.
I actually just use a 1-byte buffer with recv() (and send) and then build a bigger buffer from it, as I have heard this is a normative practice that better deals with any delays that may occur on the socket:
Code:
char byte, buffer[4096];
int i=0;
while ((recv(sock,&byte,1,0)) { /* will equal 1 as long as something's there */
buffer[i]=byte;
i++; }
This seems less problem prone than reading <=4k directly into buffer, and you can easy add a line to trap certain characters (eg, stop at \n) or set some other limit.
-
Exactly what I wanted to hear, thanks.