Question about recv

This is a discussion on Question about recv within the Networking/Device Communication forums, part of the General Programming Boards category; I have a couple of questions about socket programming that have to do with recv. I know there is a ...

  1. #1
    Registered User carrotcake1029's Avatar
    Join Date
    Apr 2008
    Posts
    398

    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.

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    Last edited by MK27; 02-26-2009 at 02:10 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    Registered User carrotcake1029's Avatar
    Join Date
    Apr 2008
    Posts
    398
    Exactly what I wanted to hear, thanks.

Popular pages Recent additions subscribe to a feed

Similar Threads

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21