• using sockets

    From Bill Cunningham@110:110/2002 to All on Wed Mar 19 19:59:36 2014
    To use SCTP instead of UDP; do I need a raw socket or just an IP socket with the number 132 instead of the macro SOCK_DGRAM?

    Bill



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Wed Mar 19 21:24:31 2014
    On Wed, 2014-03-19, Bill Cunningham wrote:
    To use SCTP instead of UDP; do I need a raw socket or just an IP socket with the number 132 instead of the macro SOCK_DGRAM?

    A raw socket /is/ an IP socket, so the question doesn't make sense.

    But I think the right answer is something else.

    As far as I can tell by googling, you're supposed to use libsctp.
    See http://www.lksctp.org/.

    I could have sworn I had seen SCTP support in the normal socket layer
    (like for UDP and TCP) but now that I look I see no sctp(7) man page documenting it. Some support might be there, but I wouldn't use it if
    it's not described on the detailed level that udp(7), tcp(7) and so on
    provide.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Bill Cunningham@110:110/2002 to All on Wed Mar 19 21:35:52 2014
    Jorgen Grahn wrote:

    A raw socket /is/ an IP socket, so the question doesn't make sense.

    But I think the right answer is something else.

    As far as I can tell by googling, you're supposed to use libsctp.
    See http://www.lksctp.org/.

    I could have sworn I had seen SCTP support in the normal socket layer
    (like for UDP and TCP) but now that I look I see no sctp(7) man page documenting it. Some support might be there, but I wouldn't use it if
    it's not described on the detailed level that udp(7), tcp(7) and so on provide.

    Ok thanks. No there is no man page in 7 or any other intro that lists SCTP. This is rather a young protocol. Now SIP is mentioned in /etc at port 5060
    of TCP or UDP.

    Bill



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Bill Cunningham@110:110/2002 to All on Thu Mar 20 00:32:09 2014
    Jorgen Grahn wrote:

    A raw socket /is/ an IP socket, so the question doesn't make sense.

    But I think the right answer is something else.

    As far as I can tell by googling, you're supposed to use libsctp.
    See http://www.lksctp.org/.

    I could have sworn I had seen SCTP support in the normal socket layer
    (like for UDP and TCP) but now that I look I see no sctp(7) man page documenting it. Some support might be there, but I wouldn't use it if
    it's not described on the detailed level that udp(7), tcp(7) and so on provide.

    That package certainly works. But what is the difference in a SOCK_UDP
    and a SOCK_RAW. I looked at the protocols ASCII file in my /etc directory
    and SCTP port 132 is listed there. Could this work?

    socket(AF_INET,SOCK_RAW,132);

    ?



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Thu Mar 20 07:20:13 2014
    On Wed, 2014-03-19, Bill Cunningham wrote:
    Jorgen Grahn wrote:

    A raw socket /is/ an IP socket, so the question doesn't make sense.

    But I think the right answer is something else.

    As far as I can tell by googling, you're supposed to use libsctp.
    See http://www.lksctp.org/.

    I could have sworn I had seen SCTP support in the normal socket layer
    (like for UDP and TCP) but now that I look I see no sctp(7) man page
    documenting it. Some support might be there, but I wouldn't use it if
    it's not described on the detailed level that udp(7), tcp(7) and so on
    provide.

    Ok thanks. No there is no man page in 7 or any other intro that lists SCTP. This is rather a young protocol.

    Not /that/ young -- there has been support in Linux for at least 5
    years or so, and your first instinct would be "let's fit it into the
    existing sockets API". But perhaps the multihoming features of SCTP
    makes that pointless.

    Actually, now I /do/ see that manual page, on the machines at work.
    It comes from libsctp though, also known as the lksctp-tools package.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Rick Jones@110:110/2002 to All on Thu Mar 20 18:23:22 2014
    Bill Cunningham <nospam@nspam.invalid> wrote:
    That package certainly works. But what is the difference in a
    SOCK_UDP and a SOCK_RAW. I looked at the protocols ASCII file in my
    /etc directory and SCTP port 132 is listed there. Could this work?

    socket(AF_INET,SOCK_RAW,132);

    Port numbers are not the same as protocol numbers and are not provided
    in the socket() call. "132" does appear to be the protocol value for IPPROTO_SCTP, however I'd suggest using the mnemonic rather than the
    magic constant.

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From Bill Cunningham@110:110/2002 to All on Thu Mar 20 21:21:10 2014
    Rick Jones wrote:

    Port numbers are not the same as protocol numbers and are not provided
    in the socket() call. "132" does appear to be the protocol value for IPPROTO_SCTP, however I'd suggest using the mnemonic rather than the
    magic constant.

    So you mean the macro you have mentioned rather than the literal decimal 132. When would SIP be used? What I want to do is write a simple client that will handshake a SIP service(r). Now I think SIP uses ports 5060 or 5061 depending on whether or not there's encryption. SIP responds to a 3 way hanhshake if the RFC I read I understand and can remember right.

    Bill



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Bill Cunningham@110:110/2002 to All on Fri Mar 21 04:54:39 2014
    Jorgen Grahn wrote:
    Not /that/ young -- there has been support in Linux for at least 5
    years or so, and your first instinct would be "let's fit it into the
    existing sockets API". But perhaps the multihoming features of SCTP
    makes that pointless.

    Actually, now I /do/ see that manual page, on the machines at work.
    It comes from libsctp though, also known as the lksctp-tools package.

    What do you mean "But perhaps the multihoming features of SCTP makes that pointless."
    I'm no expert obviously on this but I read SCTP was very versatile. And that SIP, RTP, and RTCP would use SCTP as a transport layer like it uses UDP and can use TCP. But I would think TCP would add to the payload unnecessarily.

    Bill



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Fri Mar 21 10:45:31 2014
    On Fri, 2014-03-21, Bill Cunningham wrote:
    Jorgen Grahn wrote:
    Not /that/ young -- there has been support in Linux for at least 5
    years or so, and your first instinct would be "let's fit it into the
    existing sockets API". But perhaps the multihoming features of SCTP
    makes that pointless.

    Actually, now I /do/ see that manual page, on the machines at work.
    It comes from libsctp though, also known as the lksctp-tools package.

    What do you mean "But perhaps the multihoming features of SCTP makes that pointless."

    I meant maybe the multihoming features of SCTP make it impossible to
    use the BSD sockets API: binding your socket to one address,
    connecting to one address and so on. I don't know; I haven't studied
    it.

    I'm no expert obviously on this but I read SCTP was very versatile. And that SIP, RTP, and RTCP would use SCTP as a transport layer like it uses UDP and can use TCP. But I would think TCP would add to the payload unnecessarily.

    I don't see any connection between this paragraph and the one above,
    so no comment.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Rick Jones@110:110/2002 to All on Fri Mar 21 20:15:35 2014
    Bill Cunningham <nospam@nspam.invalid> wrote:
    Port numbers are not the same as protocol numbers and are not
    provided in the socket() call. "132" does appear to be the
    protocol value for IPPROTO_SCTP, however I'd suggest using the
    mnemonic rather than the magic constant.

    So you mean the macro you have mentioned rather than the literal
    decimal 132. When would SIP be used? What I want to do is write a
    simple client that will handshake a SIP service(r). Now I think SIP
    uses ports 5060 or 5061 depending on whether or not there's
    encryption. SIP responds to a 3 way hanhshake if the RFC I read I
    understand and can remember right.

    When one creates a socket, one provides information as to what sort of addressing will be used - what the manpage under linux calls the
    "domain." This is specifying the type of addressing but does not
    provide any addressing itself. The second parameter, "type" says what
    sort of socket you want and will specify or imply the semantics of
    calls like send and recv. For example, if you specify SOCK_DGRAM then
    you will be given only one message's worth of information at most even
    if there are two messages queued to the socket and you provide enough
    buffer in the recv() call. If you specify SOCK_STREAM, you will
    recieve as much data as is in the socket whether it is one message's
    worth or N. Put another way, SOCK_DGRAM means "message" semantics and SOCK_STREAM means "byte stream" semantics. The third parameter
    specifies which transport protocol you wish to use. You can specify
    one explicitly, or you can pass-in a value of 0 in which case the
    stack will pick one for you based on the address family (first
    parameter) and socket semantics (second parameter) you have specified.
    In somewhat geeky terms, the selection of protocol determines what the
    value of the "protocol" field of the IP (or in general "network
    layer") header will be. It will be how when IP receives a datagram it
    will know to which protocol hander it should be given.

    Port numbers come into play when you either start calling connect(),
    or sendto(). They are (part of) how the transport protocol (eg TCP,
    UDP, SCTP) further demuxes traffic it has been given by IP. You
    would, presumably connect() to or sendto() a SIP service listening on
    a given port number, with a given transport protocol, at a given IP
    address.

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From Bill Cunningham@110:110/2002 to All on Sat Mar 22 01:26:09 2014
    Rick Jones wrote:
    When one creates a socket, one provides information as to what sort of addressing will be used - what the manpage under linux calls the
    "domain." This is specifying the type of addressing but does not
    provide any addressing itself. The second parameter, "type" says what
    sort of socket you want and will specify or imply the semantics of
    calls like send and recv. For example, if you specify SOCK_DGRAM then
    you will be given only one message's worth of information at most even
    if there are two messages queued to the socket and you provide enough
    buffer in the recv() call. If you specify SOCK_STREAM, you will
    recieve as much data as is in the socket whether it is one message's
    worth or N. Put another way, SOCK_DGRAM means "message" semantics and SOCK_STREAM means "byte stream" semantics. The third parameter
    specifies which transport protocol you wish to use. You can specify
    one explicitly, or you can pass-in a value of 0 in which case the
    stack will pick one for you based on the address family (first
    parameter) and socket semantics (second parameter) you have specified.
    In somewhat geeky terms, the selection of protocol determines what the
    value of the "protocol" field of the IP (or in general "network
    layer") header will be. It will be how when IP receives a datagram it
    will know to which protocol hander it should be given.

    Port numbers come into play when you either start calling connect(),
    or sendto(). They are (part of) how the transport protocol (eg TCP,
    UDP, SCTP) further demuxes traffic it has been given by IP. You
    would, presumably connect() to or sendto() a SIP service listening on
    a given port number, with a given transport protocol, at a given IP
    address.

    It seems like 0 as the 3rd parameter of scoket() would simply specify
    what is passed to the 2nd parameter. I have read that sctp man 7 page and
    you can create a one-to-one socket or a multicast one-to-many socket. Which
    I guess is what SCTP does. I think for the sake of brevity for now I'll just stick with UDP for SIP. But I guess it can run on TCP too. Maybe much
    slower.

    Bill



    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)