Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!ames!pacbell!rtech!wrs!hwajin
From: hwajin@wrs.wrs.com (Hwa Jin Bae)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: UDP bind question
Message-ID: <862@wrs.wrs.com>
Date: 28 Feb 90 19:15:02 GMT
References: <9002201434.AA04791@dcrocker.pa.dec.com> <9002201904.AA04950@yuba.WRS.COM> <1990Feb23.052940.5871@i88.isc.com>
Reply-To: hwajin@wrs.wrs.com (Hwa Jin Bae)
Organization: Wind River Systems, Emeryville, CA
Lines: 40

In article <1990Feb23.052940.5871@i88.isc.com> stevea@i88.isc.com (Steve Alexander) writes:
>You missed the worst one of all.  Options management.  Most vendors use
>sockaddr_in for TCP & UDP addresses, but everybody has a different option
>format.  Still, I agree that it's probably easier to port TLI applications 
>between systems than socket applications, if for no other reason than that 
>no two vendors can agree on where the header files go.

Talk about trivial differences.  The options data structure differs in
varying degrees but for all pratical purposes the differences can be
resolved with simple mods since in most cases the options data include
fields for the option name and the value settings.  Agreed, different
vendors may choose to use different formats, etc. but that's what 
option means: optional.  For example, options available for the
sockets SO_DEBUG, SO_REUSEADDR, SO_KEEPALIVE, SO_LINGER, etc. in 4.3 BSD
are just options.  While some of these options are for a particular
protocol -- as in TCP and SO_KEEPALIVE, SO_LINGER, etc. -- some are purely
implementation dependent -- as in SO_DEBUG, SO_USELOOPBACK, etc.  A TCP
implementation is *not* required to implement all these options or
provide interfaces to these options.  The interface definitions for the
options *should* be left undefined since vendors may choose to implement
different options, etc.  If you were to design a TLI interface would you
design in every possible option data structure format that can be ever
used?  Aside from being an impossible task, it is a highly unwise thing
to do as one cannot possibly plan for every possible vendor specific
"enhancements", etc.  If an application write chooses to use a given
option provided by a given vendor it is his responsibility to support
such software.  Besides, how many TLI applications you know actually
make heavy use of the options any way?  Even the socket applications
have "#ifdef"s everywhere for options like SO_OOBINLINE and SO_LINGER
because not all implementation support these.

>The bottom line is that AT&T should have defined protocol bindings for TLI,
>or at least put pressure on vendors of UNIX System V add-on packages to be
>more compatible with each other.

I don't like Fascism.

-- 
Hwa Jin Bae (hwajin@wrs.com)
Wind River Systems