Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Dec 2006 16:41:12 -0500
From:      Randall Stewart <rrs@cisco.com>
To:        Craig Rodrigues <rodrigc@crodrigues.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/lib/libc/net Makefile.inc sctp_sys_calls.c src/sys/sys param.h
Message-ID:  <45831678.1090201@cisco.com>
In-Reply-To: <20061215145655.GA13912@crodrigues.org>
References:  <200612151201.kBFC1qEv006825@repoman.freebsd.org> <4582A1E0.1050503@freebsd.org> <4582A6C9.8010009@FreeBSD.org> <20061215055704.A65183@xorpc.icir.org> <20061215145655.GA13912@crodrigues.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Craig Rodrigues wrote:
> On Fri, Dec 15, 2006 at 05:57:04AM -0800, Luigi Rizzo wrote:
> 
>>i think Andre's question was this:
>>normally we use {set|get}sockopt() to configure the socket
>>as desired for special features (e.g. multicast is one).
>>
>>Why is it undesirable to use the same kind of overloading
>>for sctp ?
> 
> 
> I think some of the reasons for why a new sockets API
> was introduced for SCTP was outlined in:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-14.txt
> 
> ...but I'll let Randall chime in too. :)
> 
Thats a good place to look too...

note that we do not conform yet to the latest socket api
our sctp_connectx() does not accept an additional
argument to return the sctp_assoc_t .. it will.. but
I have to get to it first :-0

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45831678.1090201>