Re: General Guidelines on bulk data through Posix Sockets
Re: General Guidelines on bulk data through Posix Sockets
- Subject: Re: General Guidelines on bulk data through Posix Sockets
- From: Andrew White <email@hidden>
- Date: Thu, 15 Dec 2005 13:25:53 +1100
Mark Gilbert wrote:
The remote machine requests and frame and my app delivers it. The frame
rate is slow (a few frames per sec)
Are you using TCP or UDP?
I dont know, sorry... I use the regular POSIX sockets stuff, bind,
connect, read etc
If you're using listen & connect, then you're using TCP. UDP doesn't use
"listen", and connect doesn't do much.
More definitively, look at your "socket" call. TCP uses SOCK_STREAM and
IPPROTO_TCP, while UDP uses SOCK_DGRAM and IPPROTO_UDP.
Sending a 30k "datagram" is interesting, since you will inevitably
suffer fragmentation. A standard ethernet supports discrete packets
of only ~1500 bytes or less. As such, large datagrams must be split
up into smaller packets for transmission, and then reassembled at the
destination.
That is exactly what I see. Interestingly when I was running client and
server on the same CPU there was no fragmentation of the message, but
when I put them on different machines things change considerably as you
describe.
When on the same server, the networking stack simply copies the entire
message from the outgoing buffer of one socket to the incoming buffer of
the other. This is true even if you use a physical interface rather than
loopback; the datagram never hits the hardware so it is never fragmented.
For interest, compare the 'mtu' values on the various interfaces:
% ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444
got it. can you elaborate on the functions I need to do this with TCP ?
aha. "recvfrom" . I shall look this up in the big book.
Note that recvfrom can also return under-sized data.
From 'man recvfrom':
---
If no messages are available at the socket, the receive call waits for a
message to arrive, unless the socket is nonblocking (see fcntl(2)) in
which case the value -1 is returned and the external variable errno set
to EAGAIN. The receive calls normally return any data available, up to
the requested amount, rather than waiting for receipt of the full amount
requested; this behavior is affected by the socket-level options
SO_RCVLOWAT and SO_RCVTIMEO described in getsockopt(2).
---
Using TCP, I'd probably recommend abstracting out the packet nature of your
communications and treat the link as a bi-directional data stream.
Messages are formatted as 'length:data'. The receiver reads a 4 byte
length byte and then slurps in the actual data. I don't think you'll have
flushing problems as long as you use write rather than stdio.
If you finish reading (or more rarely, writing) early and you don't mind
blocking, you just call read again with the remainder until you have it
all. If you do mind blocking or want to handle multiple clients, then you
need a full TCP server model with a separate TCP connection for each
client, and track where each client (and client socket) is up to. In this
case, 'select' is your friend.
If you use UDP, then recvfrom and sendto are more applicable, but you also
need to worry about recovery from lost packets (rare) and manual
packetisation (common).
--
Andrew White
--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden