| From: | |
| Date: | 18 Feb 2001 at 02:01:08 |
| Subject: | Re: bsd socket library |
Hello Andrew
On 18-Feb-01, you wrote:
> I am writing an update utility which will get a file using a custom
> protocol from a custom server - what I want to do is send the request, and
> have my single-task program do some other things.
>
> Inbetween the utility doing other things it'll call recv() now & again to
> pick up any data waiting at the socket.
A better way of doing this would be to spawn a sub process that listens for
network traffic at the appointed socket. It would signal the main task as
required.
>
> I was wondering whether data is actually physically transferred from the
> network to my machine during "the other things", in which case it'd
> already be there for when I call recv(). Or, if data is moved from the
> network only during the recv() call.
>
> I hope this makes sense!
The data will be sitting in a buffer somewhere waiting for the the recv()
(or read()) call.
I mentioned being able to alter the buffer size with setsockopt() in the
previous reply, this sounds like it might be important for your purposes.
Look up SO_RCVBUF in the autodocs or whatever text book you fancy for a
fuller answer; but briefly, each and every TCP socket has a send a recieve
buffer, and every UDP socket has a recieve buffer (not a send). The default
sizes should suffice.
As a matter of interest only (you won't need to fiddle with this), the
default size of the recieve buffer is dictated by the TCP stack. If you
examine your stack with the sysctl program then you'll see what the default
size for each buffer is. For example, with MiamiDX, run
MiamiSysctl -a
and you'll see a line for tcp and another for udp
net.inet.tcp.recvspace = 16384
net.inet.udp.recvspace = 41600
Steve
------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/451227/_/982461754/
---------------------------------------------------------------------_->