Question about recv

carrotcake1029 · 02-26-2009, 01:07 PM

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.

MK27 · 02-26-2009, 02:08 PM

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.

carrotcake1029 · 02-26-2009, 02:10 PM

Exactly what I wanted to hear, thanks.

02-26-2009, 01:07 PM	#1
carrotcake1029 Registered User Join Date: Apr 2008 Posts: 299	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.
carrotcake1029 is offline

02-26-2009, 02:08 PM	#2
MK27 subminimalist Join Date: Jul 2008 Location: NYC Posts: 3,946	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. __________________ Accuracy and integrity mean nothing if you don't make it past the censors...*PYTHAGORAS Last edited by MK27; 02-26-2009 at 02:10 PM.
MK27 is online now

02-26-2009, 02:10 PM	#3
carrotcake1029 Registered User Join Date: Apr 2008 Posts: 299	Exactly what I wanted to hear, thanks.
carrotcake1029 is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Debugging question	o_0	C Programming	9	10-10-2004 05:51 PM
Simple Question recv	MicroFiend	Networking/Device Communication	4	08-28-2004 02:28 PM
recv()	afisher	Networking/Device Communication	3	03-24-2004 05:32 PM
Question...	TechWins	A Brief History of Cprogramming.com	16	07-28-2003 09:47 PM
Question, question!	oskilian	A Brief History of Cprogramming.com	5	12-24-2001 01:47 AM