1 / 9

MIF API

IETF 79 November 11, 2010. MIF API. MIF API Requirements. Compatible with existing socket API Support for simultaneous use of multiple interfaces No changes to existing socket API API extensions must not change semantics of existing API Easy use for application developers.

cais
Download Presentation

MIF API

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF 79 November 11, 2010 MIF API

  2. MIF API Requirements • Compatible with existing socket API • Support for simultaneous use of multiple interfaces • No changes to existing socket API • API extensions must not change semantics of existing API • Easy use for application developers

  3. General considerations • Using existing socket API style mostly relying on (get/set)sockopt(...) • It should be applicable to any transport protocol sockets • API should provide both abstraction of applications from addresses and address families and exposes these information to the application developers who want to use it in any specific way. • The later introduces a number of choices which are still open issues

  4. Scope of MIF API • Get information about interfaces and their configurations • Set outgoing interface • Provide correct DNS for name resolution • What should be done per socket and what should be defined as system wide • Everything can be system wide but per socket configuration may override system wide settings

  5. Examples of API • getsockopt(...) options examples: • SO_IFACES • SO_ADDRS • SO_IFINFO • SO_DNSINFO • setsockopt(...) options examples: • SO_RTIFACE • SO_RTADDR • SO_DNS • If transport protocol allows (e.g. SCTP) SO_FAMILY

  6. MIF API Open Issues • What to introduce to applications: addresses or interfaces (names, types) or both alternatives? • Returning all addresses for all address families • Returning interfaces with / without available address families • Is there a need for a new socket level where the (set/get)sockopt apply. • For example: SOL_IFACE

  7. MIF API Open Issues • Is that feasible to introduce extention to the connect(...) call: • connect(int fd, const struct sockaddr *addr, const struct sockiface *iface, socklen_t addrlen), where one of addr or iface should be NULL. • Should the socket cache DNS server dependently on address/interface it is connected to? • How to handle connectionless sockets with DNS, which may call connect many times?

  8. MIF API Open Issues • Should an API hide DNS server selection from application • Could be open and let application developer to choose wether to mess up with DNS servers per interface or not • Generally, we have to be careful with changing socket structure because different transports use different sockets.

  9. Q & A

More Related