|
Home > Archive > Unix Programming > March 2006 > APIs for SCTP
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| phil-news-nospam@ipal.net 2006-03-15, 5:55 pm |
| I've read about and downloaded the packages sctplib and socketapi which
appears to use sctplib. But these are userland implementations of SCTP.
What I'm really looking for is how a non-userland implementation would
be used by a userland application program. I presume this would use the
basic socket interface. But there are details about SCTP that would also
make this differ somewhat. For example, identifying different streams.
What is the expected standard way (API) to use SCTP for non-userland (e.g.
in the host kernel IP stack) implementations of SCTP?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| Måns Rullgård 2006-03-15, 5:55 pm |
| phil-news-nospam@ipal.net writes:
> I've read about and downloaded the packages sctplib and socketapi which
> appears to use sctplib. But these are userland implementations of SCTP.
>
> What I'm really looking for is how a non-userland implementation would
> be used by a userland application program. I presume this would use the
> basic socket interface. But there are details about SCTP that would also
> make this differ somewhat. For example, identifying different streams.
>
> What is the expected standard way (API) to use SCTP for non-userland (e.g.
> in the host kernel IP stack) implementations of SCTP?
First you create a socket with
socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
and subscribe to SCTP notifications with
struct sctp_event_subscribe esub;
memset(&esub, 0, sizeof(esub));
esub.sctp_association_event = 1;
setsockopt(sock, IPPROTO_SCTP, SCTP_EVENTS, &esub, sizeof(esub));
Then you recvmsg() things from the socket and check for
msg_flags & MSG_NOTIFICATION, which indicates that the message payload
is a union sctp_notification.
There's obviously more that can be done, but maybe this will get you
started.
--
Måns Rullgård
mru@inprovide.com
| |
| phil-news-nospam@ipal.net 2006-03-15, 8:48 pm |
| In comp.protocols.tcp-ip M?ns Rullg?rd <mru@inprovide.com> wrote:
| phil-news-nospam@ipal.net writes:
|
|> I've read about and downloaded the packages sctplib and socketapi which
|> appears to use sctplib. But these are userland implementations of SCTP.
|>
|> What I'm really looking for is how a non-userland implementation would
|> be used by a userland application program. I presume this would use the
|> basic socket interface. But there are details about SCTP that would also
|> make this differ somewhat. For example, identifying different streams.
|>
|> What is the expected standard way (API) to use SCTP for non-userland (e.g.
|> in the host kernel IP stack) implementations of SCTP?
|
| First you create a socket with
|
| socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP);
|
| and subscribe to SCTP notifications with
|
| struct sctp_event_subscribe esub;
| memset(&esub, 0, sizeof(esub));
| esub.sctp_association_event = 1;
| setsockopt(sock, IPPROTO_SCTP, SCTP_EVENTS, &esub, sizeof(esub));
|
| Then you recvmsg() things from the socket and check for
| msg_flags & MSG_NOTIFICATION, which indicates that the message payload
| is a union sctp_notification.
|
| There's obviously more that can be done, but maybe this will get you
| started.
What I'm really looking for is a sense of the direction things are going.
E.g... which API should be used for _portable_ programs?
I'm not so sure the library approach is workable. It would seem that
such an approach requires access to raw sockets underneath. That would
make it difficult to have end users running client programs that use
some protocol over an SCTP transport.
Yeah, the above is a start. But a _complete_ document would be helpful.
Since my previous post I have found this one that looks good:
http://www.ietf.org/internet-drafts...tpsocket-12.txt
Anything better you know of?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| Nils O. Selåsdal 2006-03-16, 7:51 am |
| phil-news-nospam@ipal.net wrote:
> I've read about and downloaded the packages sctplib and socketapi which
> appears to use sctplib. But these are userland implementations of SCTP.
>
> What I'm really looking for is how a non-userland implementation would
> be used by a userland application program. I presume this would use the
> basic socket interface. But there are details about SCTP that would also
> make this differ somewhat. For example, identifying different streams.
>
> What is the expected standard way (API) to use SCTP for non-userland (e.g.
> in the host kernel IP stack) implementations of SCTP?
http://lksctp.sourceforge.net/ is a nice starting point
Examples, standard API drafts and others are linked from there.
sctplib has an addon giving you the socket api(well, almost),
described in
http://www.ietf.org/internet-drafts...tpsocket-11.txt
| |
| phil-news-nospam@ipal.net 2006-03-16, 5:53 pm |
| In comp.protocols.tcp-ip "Nils O. Sel?sdal" <NOS@utel.no> wrote:
| phil-news-nospam@ipal.net wrote:
|> I've read about and downloaded the packages sctplib and socketapi which
|> appears to use sctplib. But these are userland implementations of SCTP.
|>
|> What I'm really looking for is how a non-userland implementation would
|> be used by a userland application program. I presume this would use the
|> basic socket interface. But there are details about SCTP that would also
|> make this differ somewhat. For example, identifying different streams.
|>
|> What is the expected standard way (API) to use SCTP for non-userland (e.g.
|> in the host kernel IP stack) implementations of SCTP?
| http://lksctp.sourceforge.net/ is a nice starting point
| Examples, standard API drafts and others are linked from there.
|
| sctplib has an addon giving you the socket api(well, almost),
| described in
| http://www.ietf.org/internet-drafts...tpsocket-11.txt
Is that the API that will be used for kernel socket syscall based SCTP?
I'm going to be enabling SCTP in my Linux kernel to see how well that
works. I suspect a purely library in userland based method will incur
access restrictions (I presume it needs raw sockets) and that can be a
problem with user applications that will use SCTP.
Anyone have experience programming around either method (preferably for
other than SS7 or telephony signaling purposes)?
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
| |
| Nils O. Selåsdal 2006-03-16, 5:53 pm |
| phil-news-nospam@ipal.net wrote:
> In comp.protocols.tcp-ip "Nils O. Sel?sdal" <NOS@utel.no> wrote:
> | phil-news-nospam@ipal.net wrote:
> |> I've read about and downloaded the packages sctplib and socketapi which
> |> appears to use sctplib. But these are userland implementations of SCTP.
> |>
> |> What I'm really looking for is how a non-userland implementation would
> |> be used by a userland application program. I presume this would use the
> |> basic socket interface. But there are details about SCTP that would also
> |> make this differ somewhat. For example, identifying different streams.
> |>
> |> What is the expected standard way (API) to use SCTP for non-userland (e.g.
> |> in the host kernel IP stack) implementations of SCTP?
> | http://lksctp.sourceforge.net/ is a nice starting point
> | Examples, standard API drafts and others are linked from there.
> |
> | sctplib has an addon giving you the socket api(well, almost),
> | described in
> | http://www.ietf.org/internet-drafts...tpsocket-11.txt
>
> Is that the API that will be used for kernel socket syscall based SCTP?
Yes.
For linux, some of the extended calls are placed in a library, again,
see http://lksctp.sourceforge.net/
> I'm going to be enabling SCTP in my Linux kernel to see how well that
> works. I suspect a purely library in userland based method will incur
> access restrictions (I presume it needs raw sockets) and that can be a
> problem with user applications that will use SCTP.
Yes.
> Anyone have experience programming around either method (preferably for
> other than SS7 or telephony signaling purposes)?
That question is too vague..
| |
| phil-news-nospam@ipal.net 2006-03-16, 8:49 pm |
| In comp.protocols.tcp-ip "Nils O. Sel?sdal" <noselasd@asgaard.homelinux.org> wrote:
| phil-news-nospam@ipal.net wrote:
|> In comp.protocols.tcp-ip "Nils O. Sel?sdal" <NOS@utel.no> wrote:
|> | phil-news-nospam@ipal.net wrote:
|> |> I've read about and downloaded the packages sctplib and socketapi which
|> |> appears to use sctplib. But these are userland implementations of SCTP.
|> |>
|> |> What I'm really looking for is how a non-userland implementation would
|> |> be used by a userland application program. I presume this would use the
|> |> basic socket interface. But there are details about SCTP that would also
|> |> make this differ somewhat. For example, identifying different streams.
|> |>
|> |> What is the expected standard way (API) to use SCTP for non-userland (e.g.
|> |> in the host kernel IP stack) implementations of SCTP?
|> | http://lksctp.sourceforge.net/ is a nice starting point
|> | Examples, standard API drafts and others are linked from there.
|> |
|> | sctplib has an addon giving you the socket api(well, almost),
|> | described in
|> | http://www.ietf.org/internet-drafts...tpsocket-11.txt
|>
|> Is that the API that will be used for kernel socket syscall based SCTP?
| Yes.
| For linux, some of the extended calls are placed in a library, again,
| see http://lksctp.sourceforge.net/
All socket functions are technically in a library. So how does SCTP
differ? And note that I am asking about portable programing specifics
so that programs I do develop using SCTP will compile, link, and run
on any platform once that platform is SCTP-ready.
Is there to be a header to always include for access to SCTP sockets
above and beyond what would be included for access to TCP or UDP sockets?
If so, then shouldn't that be specified by some standard? If it is,
which standard?
Is there to be a library to always link in for access to SCTP sockets?
above and beyond what would be included for access to TCP or UDP sockets?
If so, then shouldn't that be specified by some standard? If it is,
which standard?
What things (header, library, symbols defined in other headers, symbols
defined and exported from other libraries) should I look for in some
platform to tell if it is SCTP-ready?
It seems certain basic information is still not being provided by many
SCTP documentations I find. I would have hoped much of this would be
defined in RFCs. But it does not seem to be. I'm just trying to get
that basic information.
|> I'm going to be enabling SCTP in my Linux kernel to see how well that
|> works. I suspect a purely library in userland based method will incur
|> access restrictions (I presume it needs raw sockets) and that can be a
|> problem with user applications that will use SCTP.
| Yes.
So I will focus strictly on a kernel based portable API.
|> Anyone have experience programming around either method (preferably for
|> other than SS7 or telephony signaling purposes)?
| That question is too vague..
Since I will focus strictly on a kernel based portable API, then I guess
that is the only thing I should ask about to see who has programming
experience.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
|
|
|
|
|