The IP over ATM Mailing List Archive by date

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

 >> thats what i am proposing - not another family of socktes, but just 
 >> of adresses
 >
 >> sockaddr_arequpa = (string form" ipaddr+atmaddr+qos
 >
 >> then the API is unchanged, and applications just connect, or bind, on 
 >> these new addresses 
 >
 >ok, I got you now. What you are proposing is an api that looks like the 
 >standard socket api but allows to add QoS functionality (eg. Arequipa or RSVP)
 
 >Basically you pass extra information through the usual calls, instead of 
 >adding extra calls. You'll have to modify your application anyway to make use 
 >of the extra information.

nope - if the application is reasonbly well written, it will simply be
able to to a 
gethostbyname
and
getservbyname
and fill in some structures and without knowing it, get a signalled IP
over ATM or RSVP/IP call....

 >The use of either API doesn't change the functionality you get from the 
 >underlying QoS mechanism, be it RSVP or Arequipa. 

true!

 >I don't favor either solution. Is there any consensus on what type of API 
 >will/should be used with RSVP?

pwell, i for one want to minimse changes to the API, and also minimse
the NUMEBR of system calls made to achive any given function

for example, using a new address family, sendto() and recvfrom() coud
_re-specify_ the QoS on a packet by packet basis 

recvfrom() could return a modified QoS (e.g. from controlled load or
ABR)

and given these events might be on the same order of timescale as the
application is dealing with packets, the sys call (even winsock
dll/asynch call overhead) is to be avoided where possible...

but i agree, i am not trying to alter your idea, just the interface

cheers

 jon