(no subject)

>>>the next packet-size as part of the prior packet read.
>>
>>        That's an optimization that works on some systems;
>>not on others.   Keep the protocol free from platform specifics.

>Folks, I am getting a little tired of this line of response
>without any thought behind it.  There is absolutely nothing
>platform-specific about preferring 1 read over two reads.

The original poster was right. There is no fundamental reason 
why system calls should be considerably more expensive than
proceedure calls. This is usually true in UNIX because the 
kernels are often baddly designed and cause substantial locking
overheads.


In any case the standard principle when reads are expensive is 
that the application program should accept as much as is avaliable 
on each read. Thus there is no need to specify the number of bytes 
past the previous packet. either the data is there in which case the 
read returns all relevant bytes (and more) or the data has not yet been
sent in which case one wants to return with a partially filled buffer 
in any case. 

I fail to see any efficiency consideration in connection with the 
fixed lookahead limit. In addition this is an optimisation, hence a 
heuristic approach (eg a 15 byte lookahead is usually sufficient) is
the most appropriate solution.


There have been some comments made about UNIX's somewhat exccentric
behaviour concerning sockets. It is pretty well unique in allowing 
multiple processes to share a socket to a third party without having
a common communication path. This seems to be the source of the 
requirement that processes avoid reading past the end of the packet. 
This is a very system dependent constraint and since it is a pretty
marginal optimisation at best I suggest it be ignored. 

Note that most programs which exploit the socket sharing ability have
to also support a general inter-process message passing scheme. 

In return for this questionable optimisation we are asked to accept 
a fixed upper bound on the packet size. This is simply not acceptable.
It optimises the wrong condition.

-- 
Phillip M. Hallam-Baker            Not speaking for anoyone else
hallam@w3.org http://www.w3.org/hypertext/WWW/People/hallam.html
Information Superhighway -----> Hi-ho! Yow! I'm surfing Arpanet!

Received on Wednesday, 26 July 1995 11:46:56 UTC