Subject: [Tsvwg] SCTP socket API - Kernel level interface vs. user level interface

From: Mark Butler <[email-masked]>
Date: Thu, 16 Mar 2006 11:40:23 -0700

There is a general problem with implementing an extensive interface 
using setsockopt, namely keeping the ABI stable, so that applications 
are forward and backward compatible across different kernel versions.  
Many operating systems have a policy of never removing a kernel 
interface, so deprecated interfaces have to be maintained indefinitely.  
There are other related problems.

Proposed solution:

(1) Change most of the draft API socket options into API functions like 
sctp_sendmsg or sctp_recvmsg.   Most such functions would take as 
arguments a socket descriptor, and association id, and a structure 
essentially identical to the ones that are defined now.  The option name 
and length would not need to be passed.

For example one might have:

int sctp_get_associnfo(int sd, int assoc_id, struct sctp_associnfo *); and
int sctp_set_associnfo(int sd, int assoc_id, struct sctp_associnfo *);

(2) Define two deprecated wrapper functions: sctp_setsockopt() and 
sctp_getsockopt().  These functions would translate the socket options 
as currently defined into whatever lower level interface the SCTP 
implementation uses.

Rationale:

The user level interface is what should be standardized, not the kernel 
level interface.  The kernel interface necessary to support the user 
level interface would be left up to the implementation, instead of being 
specified in explicit detail, as is the case now. 

Doing it this way allows systems to support multiple, potentially 
incompatible versions of the interface simultaneously using library 
versioning, so various problems could be fixed without breaking existing 
applications.

Comments?

 - Mark

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg