| Age | Commit message (Collapse) | Author |
|---|
|
Fixing spelling.
|
|
Taken almost verbatim from @RaimoNiskanen's comment from [10 years ago](http://erlang.2086793.n4.nabble.com/strange-behaviour-of-gen-tcp-connect-tp2113918p2113920.html).
|
|
|
|
|
|
Implement socket options recvtclass, recvtos, recvttl and pktoptions.
Document the implemented socket options, new types and message formats.
The options recvtclass, recvtos and recvttl are boolean options that
when activated (true) for a socket will cause ancillary data to be
received through recvmsg(). That is for packet oriented sockets
(UDP and SCTP).
The required options for this feature were recvtclass and recvtos,
and recvttl was only added to test that the ancillary data parsing
handled multiple data items in one message correctly.
These options does not work on Windows since ancillary data
is not handled by the Winsock2 API.
For stream sockets (TCP) there is no clear connection between
a received packet and what is returned when reading data from
the socket, so recvmsg() is not useful. It is possible to get
the same ancillary data through a getsockopt() call with
the IPv6 socket option IPV6_PKTOPTIONS, on Linux named
IPV6_2292PKTOPTIONS after the now obsoleted RFC where it originated.
(unfortunately RFC 3542 that obsoletes it explicitly undefines
this way to get packet ancillary data from a stream socket)
Linux also has got a way to get packet ancillary data for IPv4
TCP sockets through a getsockopt() call with IP_PKTOPTIONS,
which appears to be Linux specific.
This implementation uses a flag field in the inet_drv.c socket
internal data that records if any setsockopt() call with recvtclass,
recvtos or recvttl (IPV6_RECVTCLASS, IP_RECVTOS or IP_RECVTTL)
has been activated. If so recvmsg() is used instead of recvfrom().
Ancillary data is delivered to the application by a new return
tuple format from gen_udp:recv/2,3 containing a list of
ancillary data tuples [{tclass,TCLASS} | {tos,TOS} | {ttl,TTL}],
as returned by recvmsg(). For a socket in active mode a new
message format, containing the ancillary data list, delivers
the data in the same way.
For gen_sctp the ancillary data is delivered in the same way,
except that the gen_sctp return tuple format already contained
an ancillary data list so there are just more possible elements
when using these socket options. Note that the active mode
message format has got an extra tuple level for the ancillary
data compared to what is now implemented gen_udp.
The gen_sctp active mode format was considered to be the odd one
- now all tuples containing ancillary data are flat,
except for gen_sctp active mode.
Note that testing has not shown that Linux SCTP sockets deliver
any ancillary data for these socket options, so it is probably
not implemented yet. Remains to be seen what FreeBSD does...
For gen_tcp inet:getopts([pktoptions]) will deliver the latest
received ancillary data for any activated socket option recvtclass,
recvtos or recvttl, on platforms where IP_PKTOPTIONS is defined
for an IPv4 socket, or where IPV6_PKTOPTIONS or IPV6_2292PKTOPTIONS
is defined for an IPv6 socket. It will be delivered as a
list of ancillary data items in the same way as for gen_udp
(and gen_sctp).
On some platforms, e.g the BSD:s, when you activate IP_RECVTOS
you get ancillary data tagged IP_RECVTOS with the TOS value,
but on Linux you get ancillary data tagged IP_TOS with the
TOS value. Linux follows the style of RFC 2292, and the BSD:s
use an older notion. For RFC 2292 that defines the IP_PKTOPTIONS
socket option it is more logical to tag the items with the
tag that is the item's, than with the tag that defines that you
want the item. Therefore this implementation translates all
BSD style ancillary data tags to the corresponding Linux style
data tags, so the application will only see the tags 'tclass',
'tos' and 'ttl' on all platforms.
|
|
|
|
|
|
This commit attempts to clarify some of the guarantees given by
the TCP standard when issuing close. This is quite a complex
topic so there are probably corner cases still left, but this
at least tells the user that things can go wrong when doing
a close.
|
|
For gen_tcp, gen_udp and gen_sctp controlling_process/2 can return
badarg if erlang:port_connect/2 fails with badarg. This can easily
happen if the new owner is not alive but in some race condition also
when the socket is closed right before port_connect/2 (and after the
previous socket function)
This commit documents this behaviour.
|
|
Fix some older errors as well.
|
|
* lukas/erts/testfixes-19:
erts: Increase bif and nif call_time trace test
erts: Fix distribution_SUITE:bulk_send_bigbig on windows
erts: Ensure bs_add_overflow test has enough memory
kernel: Better explain controlling_process' tcp behaviour
kernel: Fix t_recv_delim on bsd
os_mon: Make sure to start/stop os_mon in tests correctly
ssl: Fix use_interface dist_SSL test
erl_interface: Fix signed int overflow tc bug
erts: fix atom_roundtrip_r15b tc
erts: Require more memory for debug tests
|
|
|
|
|
|
* saleyn/uds/PR-612/OTP-13572:
Rewrite inet* for address family 'local'
Rewrite inet_drv for AF_LOCAL
Assign externally open fd to gen_tcp (UDS support)
Conflicts:
erts/preloaded/ebin/prim_inet.beam
lib/kernel/doc/src/gen_tcp.xml
lib/kernel/doc/src/gen_udp.xml
lib/kernel/src/inet6_sctp.erl
lib/kernel/test/inet_SUITE.erl
|
|
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
Language cleaned up by technical writers from Combitech.
Proofreading and corrections by Björn Gustavsson and
Hans Bolinder.
|
|
|
|
When a AF_LOCAL file descriptor is created externally (e.g. Unix
Domain Socket) and passed to `gen_tcp:listen(0, [{fd, FD}])`, the
implementation incorrectly assigned the address family to be equal
to `inet`, which in the inet_drv driver translated to AF_INET instead
of AF_LOCAL (or AF_UNIX), and an `einval` error code was returned.
This patch fixes this problem such that the file descriptors of the
`local` address family are supported in the inet:fdopen/5,
gen_tcp:connect/3, gen_tcp:listen/2, gen_udp:open/2 calls
|
|
Fix mistakes found by 'xmllint'.
|
|
|
|
If the driver queue is empty, or the user is requesting a 'read'
shutdown, then the shutdown() syscall is performed synchronously, as
per the old version of shutdown/2.
However, if the user is requesting a 'write' or 'read_write' shutdown,
and there is data in the driver queue for the socket, then the
shutdown() syscall is delayed and handled asynchronously when the
driver queue is written out.
This version of shutdown solves a number of issues with the old
version. The two main solutions it offers are:
* It doesn't block when the TCP peer is idle or slow. This is the
expected behaviour when shutdown() is called: the caller needs
to be able to continue reading from the socket, not be prevented
from doing so.
* It doesn't truncate the output. The current version of
gen_tcp:shutdown/2 will truncate any outbound data in the driver
queue after about 10 seconds if the TCP peer is idle of slow. Worse
yet, it doesn't even inform anyone that the data has been
truncated: 'ok' is returned to the caller; and a FIN rather than
an RST is sent to the TCP peer.
For a detailed description of all the problems with the old version
of shutdown, please see the EEP Light that was written to justify
this patch.
|
|
Conflicts:
erts/doc/src/notes.xml
erts/preloaded/ebin/prim_inet.beam
erts/vsn.mk
lib/kernel/doc/src/notes.xml
lib/kernel/vsn.mk
|
|
|
|
Add the {active,N} socket option, where N is an integer in the range
-32768..32767, to allow a caller to specify the number of data messages to
be delivered to the controlling process. Once the socket's delivered
message count either reaches 0 or is explicitly set to 0 with
inet:setopts/2 or by including {active,0} as an option when the socket is
created, the socket transitions to passive ({active, false}) mode and the
socket's controlling process receives a message to inform it of the
transition. TCP sockets receive {tcp_passive,Socket}, UDP sockets receive
{udp_passive,Socket} and SCTP sockets receive {sctp_passive,Socket}.
The socket's delivered message counter defaults to 0, but it can be set
using {active,N} via any gen_tcp, gen_udp, or gen_sctp function that takes
socket options as arguments, or via inet:setopts/2. New N values are added
to the socket's current counter value, and negative numbers can be used to
reduce the counter value. Specifying a number that would cause the socket's
counter value to go above 32767 causes an einval error. If a negative
number is specified such that the counter value would become negative, the
socket's counter value is set to 0 and the socket transitions to passive
mode. If the counter value is already 0 and inet:setopts(Socket,
[{active,0}]) is specified, the counter value remains at 0 but the
appropriate passive mode transition message is generated for the socket.
This commit contains a modified preloaded prim_inet.beam due to changes in
prim_inet.erl.
Add tests for {active,N} mode for TCP, UDP, and SCTP sockets.
Add documentation for {active,N} mode for inet, gen_tcp, gen_udp, and
gen_sctp.
|
|
|
|
* lukas/kernel/fix-gen_udp_tcp-leak/OTP-10094:
Add testcase for controlling_process(P,self())
Fix port leaking after controlling_process(Port, self())
|
|
|
|
* same as ip option
|
|
|
|
* UDP: ulticast_if, multicast_loop and multicast_ttl,
add_membership and drop_membership
* Inet: bit8, buffer, deliver, high_watermark, linger and
low_watermark
|
|
|
|
Add case to handle the situation when someone call
{gen_tcp,gen_udp}:controlling_process(Port, self()). Also improve spec
and doc from gen_udp and gen_sctp for controlling_process/2.
To reproduce the issue, open an UDP port:
4> {ok,Port} = gen_udp:open(9000, [binary]).
{ok,#Port<0.587>}
5> gen_udp:controlling_process(Port, self()).
ok
Simulate error:
6> 1=2.
** exception error: no match of right hand side value 2
Here is the leak:
7> inet:i().
Port Module Recv Sent Owner Local Address Foreign Address State
Type
581 inet_udp 0 0 <0.31.0> *:cslistener *:* BOUND
DGRAM
ok
|
|
The {error, enfile} return value is badly misleading and confusing for
this case, since the Posix ENFILE errno value has a well-defined meaning
that has nothing to do with Erlang ports. The fix changes the return
value to {error, system_limit}, which is consistent with e.g. various
file(3) functions. inet:format_error/1 has also been updated to support
system_limit in the same manner as file:format_error/1.
|
|
|
|
Courtesy of William B. Morgan at Bigpoint Inc.
|
|
|
|
* Assure store_cookies (and verify_cookies) is documented instead of the
nonexistent store_cookie and verify_cookie.
* Make sure the cookies option is not called cookie in comments.
* Sprinkle <c>...</c> arround symbols and code snippets in text.
* Grammar, wording, and punctuation fixes.
* Formalize See gen_tcp:connect/3,4 using <seealso>.
|
|
When the HTTP packet mode has been enabled for a socket,
the ssl and gen_tcp modules have different error indications
when there is an error while parsing the HTTP header:
ssl:recv(SSLSocket, 0) -> {ok, {http_error, _Str}}
gen_tcp:recv(Socket, 0) -> {error, {http_error, _Str}}
We have decided to change gen_tcp:recv/2 to behave the same
way as ssl:recv/2. That means that there will be always be
an ok tuple if data could be succefully read from the socket,
and an error tuple if there was a read error at the socket level.
|
|
|
