Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: x/net/sctp: new package #22191

Open
higebu opened this issue Oct 10, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@higebu
Copy link

commented Oct 10, 2017

Background

This proposal will make easy to develop SCTP based applications such as HSS or MME in cellular networks.

I'd like to add this proposal to core library, because the one-to-one style SCTP interface on Linux is very similar to TCP interface. If we make an another package or add this to golang.org/x/net, it will make
large copy of code from net and internal/poll package.

Proposal

Add one-to-one style SCTP support to net package.

  • Support sctp/sctp4/sctp6 in net.Listen and net.Dial.
  • Add 3 functions and 3 structs to net packages.
    • structs
      • SCTPAddr
      • SCTPConn
      • SCTPListener
    • functions
      • func DialSCTP(string, *SCTPAddr, *SCTPAddr) (*SCTPConn, error)
      • func ListenSCTP(string, *SCTPAddr) (*SCTPListener, error)
      • func ResolveSCTPAddr(string, string) (*SCTPAddr, error)

This proposal supports only one-to-one style interface with SOCK_STREAM.

@gopherbot gopherbot added this to the Proposal milestone Oct 10, 2017

@gopherbot gopherbot added the Proposal label Oct 10, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Oct 10, 2017

Change https://golang.org/cl/69410 mentions this issue: net: initial SCTP support

higebu added a commit to higebu/go that referenced this issue Oct 11, 2017

net: initial SCTP support
Fixes golang#22191

Change-Id: Icbebf73acd6f9965e554b780d726add0a4c61036
@LionNatsu

This comment has been minimized.

Copy link
Contributor

commented Oct 13, 2017

BTW, one-to-one style SCTP is good as an alternative of TCP, but should we implement multi-stream and multi-homing as well? They are very useful for some scenario in LAN.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Oct 13, 2017

Even with any necessary code duplication, I think this should be in x/net/* and not in the standard library. SCTP is too fringe for the standard library.

See also: https://golang.org/doc/faq#x_in_std

@higebu

This comment has been minimized.

Copy link
Author

commented Oct 13, 2017

@LionNatsu See #9334. I think we need to resolve this issue for that.

@higebu

This comment has been minimized.

Copy link
Author

commented Oct 13, 2017

@bradfitz OK. I'll try to implement it into x/net.

@mikioh mikioh changed the title proposal: net: Support SCTP proposal: x/net/sctp: new package Nov 29, 2017

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2017

Given that the Linux kernel is actually doing the SCTP implementation and this is just a new socket enumeration, it seems like a solution to #15021 should happen first, and then this can be completely
out-of-standard-library changes. A tiny amount of new code in x/net would not be a big deal. The pending CL has lots of code in the standard library as well, which we'd like to avoid.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2017

Putting on hold until #15021 is done.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2019

I believe that #15021 is not necessary for this issue. Go 1.12 and above fix #24331 and anyone who wants to implement minor protocols (like SCTP) can achieve their goal without vendoring/tweaking/reimplementing the runtime-integrated network poller.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2019

This proposal supports only one-to-one style interface with SOCK_STREAM.

Well, I still don't see any good reason why this "one-to-one mapping-only SCTP" implementation should stay in the x/net repository. Just skimmed godoc.org and found https://godoc.org/github.com/ishidawataru/sctp; I guess that's enough for people who need to work on mobile radio-area/core networks.

If we really need an SCTP package, it might be better to have a package that follows RFC 4960bis (currently working group draft at IETF tsv-wg), supports both latest FreeBSD and Linux SCTP implementations (the past few years Linux implementation rushing to catch up the latest features) and has well-considered API surfaces; for example, TLS-over-SCTP w/ non-full handshake? no thanks, focusing on flexible associations? yup, but CMT and various flow/congestion-control algorithms should be pluggable.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2019

I believe that #15021 is not necessary for this issue

and there's another roadblock: #17244

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.