Xref: utzoo comp.dcom.lans:1522 comp.protocols.tcp-ip:3937 comp.protocols.iso:109
Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!ucsd!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TLI transport specific addresses
Message-ID: <1084@nusdhub.UUCP>
Date: 1 Jul 88 17:47:33 GMT
References: <297@scolex>
Organization: National University, San Diego
Lines: 60

in article <297@scolex>, timon@sco.COM (timon) says:
> 
> 
> 		a puzzle for the net:
> 
> AT+T chose not to define an addressing scheme for their
> TLI library.  Instead they require the user program to pass
> to the transport a pointer to an undefined address structure.
> This requires that the user program know what address structure
> the transport is expecting, and therefore makes each user
> program transport specific.

I think you missed something, as I did.  The "address" structure
in question is a standard "netbuf" structure.  To write a transport
non-spesific program you must do one extra step, but this is no
big deal; to whit:

When you issue "t_open" on the provider, you will receive a set of
"default" options for the provider, among these are the maximum
size, in characters, of an address and the maximum sizes of
the various data types.  These will dictate your address et al.

It is important to remember that the "addresses" refered to by
this are the _names_ assigned to the endpoint in question and
_not_ the physical address/serial_number of the board, to whit:
the address may be associated with different hardware at different
times.  As such addresses are arbitrary character strings, usually
numonic, with several "suggested guidleines" for safe naming.
The transport provider bears the burden of translating this
into a media-dependant address, and as such this is not the
problem of your software.  The media-address may also be retreived
through one call (I forget which...)

Because the options related to data-packet size et al are prone
to change after connection ("negotiable pramaters") to be
transport independant you should issue t_getinfo and adjust
your sizes accordingly.  This is _IMPORTANT_ when you are
using a hetrogenous machine types on the same transport, or when
you are bridging between network types.  t_getinfo returns
the "smalest restricted maximums" and therefore prevents
misshaps.

Like dialing a phone, the actual address you use depends on
what you want to reach, and therefore the user has to know
something about what is expected, but the lower-level group
and sub-group or serial-number issues are not really a valid
issue when you are writing the application.  If you are
writing a driver, great things can be done for you by aquiring
the network programmers guide (marginally helpful) and an
"unpublished" refrence you can get free with your source code
licence or by request (don't know how much) which I call the
magic book, and they _sometimes_ call the "porting rules"
though this is exactly what they are not, this doccument
is teh one which actually gets around to telling you things
you need to know but are only hinted at in the other
documentation.

"Conssume... enjoy...  Tomorrow is for the testing..."

Rob.