| Age | Commit message (Collapse) | Author |
|---|
|
Test case for testing socket option {active, true} after
association is peeled off.
|
|
|
|
Also allow mixed address families to bind, since the first address on
a multihomed sctp socket must be bound with bind, while the rest are
to be bound using sctp_bindx.
At least Linux supports adding address of mixing families.
Make inet_set_faddress function available also when HAVE_SCTP is not
defined, since we use it to find an address for bind to be able to mix
ipv4 and ipv6 addresses.
|
|
Setting several ip addresses for an SCTP socket worked only for IPv4
on Linux. For IPv6 and for other for instance Solaris and FreeBSD, it
failed with badarg for both IPv4 and IPv6.
For the first address specified to gen_sctp:open, bind is now called,
while for any following addresses, sctp_bindx is called, repeatedly,
with one address at a time. Previously, sctp_bindx was called for all
addresses in one go, with the addresses in reverse order, and bind was
not called at all if more than one address was specified. Both
Solaris and FreeBSD requires bind to have been called before calling
sctp_bindx, and FreeBSD additionally allows at most one address at a
time in the call to sctp_bindx.
For some versions of Linux, for instance SuSE 10, the port can be 0
only for the call to bind but not for subsequent calls to sctp_bindx,
so replace with the port number assigned by the operating system.
|
|
|
|
inet:port/1 on peeled off socket returns 0. Bug? Who's?
|
|
It is better that gen_sctp:open/0-2 returns the informative Posix
return code {error,eprotonosupport} than previously {error,badarg}
when SCTP is not supported since it is so platform dependent.
|
|
|
|
The socket handler needs more flexibility regarding which events
are expected to be received.
|
|
|
|
|
|
|
|
Also fix tests for new prim_inet:open function.
|
|
raimo/sctp-getsetopts-dev/OTP-9544
Conflicts:
erts/emulator/drivers/common/inet_drv.c
lib/kernel/test/gen_sctp_SUITE.erl
|
|
Socket options 'sndbuf', 'recbuf' and 'linger were read from
the SCTP protocol layer instead of from the socket protocol layer.
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
* rani/sctp-sndrcvinfo/OTP-8795:
Fix xfer_active close expection for Solaris behaviour
Keep default #sctp_sndrcvinfo{} fields on gen_sctp:send/4
Fill in sinfo_assoc_id in struct sctp_sndrcvinfo for getopt()
Conflicts:
lib/kernel/test/gen_sctp_SUITE.erl
|
|
|
|
|
|
inet:setopts(S, [{linger,{true,2}}]) returned {error,einval} for
SCTP sockets. The inet_drv had a bug when checking the option size.
|
|
* sc/sctp-connect-nowait:
Implement a non-blocking SCTP connect
OTP-8414 There are new gen_sctp:connect_init/* functions that initiate an
SCTP connection without blocking for the result. The result is
delivered asynchronously as an sctp_assoc_change event. (Thanks
to Simon Cornish.)
|
|
This patch adds a new set of functions - gen_sctp:connect_init/* that initiate
an SCTP connection without blocking for the result. The result is delivered
asynchronously as an sctp_assoc_change event.
The new functions have the same API as documented for gen_sctp:connect/* with
the following exceptions:
* Timeout is only used to supervise resolving Addr (the peer address)
* The possible return values are ok | {error, posix()}
The caller application is responsible for receiving the #sctp_assoc_change{}
event and correctly determining the connect it originated from (for example,
by examining the remote host and/or port). The application should have at
least {active, once} or use gen_sctp:recv to retrieve the connect result.
The implementation of gen_sctp:connect suffers from a number of
shortcomings which the user may avoid by using gen_sctp:connect_init and
adding code to receive the connect result.
First, irrespective of the Timeout value given to gen_sctp:connect, the OS
attempts and retries the SCTP INIT according to various kernel parameters. If
the Timeout value is shorter than the entire attempt then the application will
still receive an sctp_assoc_change event after the {error, timeout} is
returned from the initial call. This could be somewhat confusing (either to
the application or the designer!) especially if the status is
comm_up. Subsequent calls to connect before the OS has finished this process
return {error, ealready} which may also be counter-intuitive.
Second, there is a race-condition (documented in comments in inet_sctp.erl)
that can cause the wrong sctp_assoc_change record to be returned to an
application calling gen_sctp:connect. The race seriously affects connection
attempts when using one-to-many sockets.
|
|
|
