Re: Melting the Internet?

Bill Ryan (bryan@wpine.com)
Tue, 9 May 1995 11:20:32 -0800


>
>> OK. Tim and I spent some time talking about this. Probably the real issue
>> is that the API to tcp doesn't give any info about what's happening on the
>> connection (network level virtual circuit). With real-time stuff, the
>> sender needs to delay capturing a frame (e.g.) until bw exists to send it
>> end-to-end with minimal delay.
>
> Two ways to tell if a TCP pipe is so full that a write() to it
>would cause to process to block are:
> 1. put the file descriptor in non-blocking mode so that the
> write returns with an error code of EWOULDBLOCK
> 2. use select() to test if a write to the file descriptor is
> is possible. With select() you can have it answer right away
> or you can tell it to wait N milliseconds for the pipe to empty
> before giving up.
>
> Also there is support for having signals delivered when input or
>output is possible on a file descriptor (I've never used this
>or output myself but I suspect it is possible).
>
Currently, the MacTCP network API for the Macintosh is not a Unix stream based API (Apple's created there own network API).

However, the MacTCP driver's interface offers the TCPStatus call which does offer the required information for current connection status (i.e. send/receive window information plus other stuff). This costs an extra trap call besides the TCPSend, but I believe this would have minimal impact on performance.

Apple's "future" OpenTransport will change all this (hopefully for the better).

I'm not too familiar with MS Window's WinSock interface, what you suggest may work for it as I believe it uses a Unix type network API????.

Bill
______________________________________________________________________
Bill Ryan "Keeping You Connected"
Principal Software Engineer "CU-SeeMe Master Licensee"
White Pine Software, Inc. http://www.wpine.com
40 Simon Street PH: 603-886-9050
Nashua, NH 03060 FAX: 603-886-9051