site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) Mark Gilbert wrote: 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 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). --- -- 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. 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. 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). This email sent to site_archiver@lists.apple.com