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.
