| Age | Commit message (Collapse) | Author |
|
Fixes #78531
Change-Id: I7ccd84f9a3ced75c86b7540d84309e094717ffba
GitHub-Last-Rev: 03a8ee1fd132a597e1a1e30add7cf7ba00ac114a
GitHub-Pull-Request: golang/go#78532
Reviewed-on: https://go-review.googlesource.com/c/go/+/762780
Auto-Submit: Nicholas Husin <husin@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Nicholas Husin <nsh@golang.org>
|
|
Add context aware dial functions for TCP, UDP, IP and Unix networks.
Fixes #49097
Updates #59897
Change-Id: I7523452e8e463a587a852e0555cec822d8dcb3dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/490975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
|
|
Fixes #74634
Change-Id: I21196c4aef1b717bfda0b54e61b35e83cfa9dc1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/689075
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <mark@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Change-Id: I351b88276307c8d21e43b5b992b30b64996d129c
Reviewed-on: https://go-review.googlesource.com/c/go/+/620777
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
|
|
Before this patch, the documentation of Dialer.Control and
ListenConfig.Control did not specify what networks would be
passed to the Control function other than the "tcp" case.
It was thus challenging to use the Control function to filter
out certain networks. This patch documents all known networks.
Fixes #69693
Change-Id: I2ab10d68c4e4fac66d51d2cc232f02cf3b305e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/617055
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
A previous change [1] was introduced to enable MPTCP by default
for both the clients and servers, based on the discussions [2] in
golang#56539, where MPTCP would be an opt-in for a release or
two, and then would become an opt-out.
This change was not accepted at the time because the support for
a few socket options was missing [3]. Now that this support has been
added [4] and backported to stable versions not to block MPTCP
deployment with Go, it sounds like a good time to reconsider the use
of MPTCP by default.
Instead of enabling MPTCP on both ends by default, as a first step,
it seems safer to change the default behaviour only for the server
side (Listeners). On the server side, the impact is minimal: when
clients don't request to use MPTCP, server applications will create
"plain" TCP sockets within the kernel when connections are accepted,
making the performance impact minimal. This should also ease
experiments where MPTCP is enabled by default on the client side
(Dialer).
The changes in this patch consist of a duplication of the mptcpStatus
enumeration to have both a mptcpStatusDial and a mptcpStatusListen,
where MPTCP is enabled by default in mptcpStatusListen, but disabled
by default in mptcpStatusDial. It is still possible to turn MPTCP support
on and off by using GODEBUG=multipathtcp=1.
[1] https://go-review.googlesource.com/c/go/+/563575
[2] https://go.dev/issue/56539#issuecomment-1309294637
[3] https://github.com/multipath-tcp/mptcp_net-next/issues/383
[4] https://github.com/torvalds/linux/commit/bd11dc4fb969ec148e50cd87f88a78246dbc4d0b
[5] https://www.mptcp.dev/faq.html#why--when-should-mptcp-be-enabled-by-default
Updates #56539
Change-Id: I1ca0d6aaf74d3bda5468af135e29cdb405d3fd00
GitHub-Last-Rev: 5f9f29bfc13ad4ea6bfd1e0fc95a91bd824f4048
GitHub-Pull-Request: golang/go#69016
Reviewed-on: https://go-review.googlesource.com/c/go/+/607715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
Fixes #62254
Fixes #48622
Change-Id: Ida598e7fa914c8737fdbc1c813bcd68adb5119c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/542275
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: Ib7c4baf0247c421954aedabfbb6a6af8a08a8936
Reviewed-on: https://go-review.googlesource.com/c/go/+/540021
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
There is no need to handwrite the "last" function, the bytealg package already provides "LastIndexByteString".
Change-Id: I6000705bffe8450a10cf8f3fa716a8d4605ada1f
GitHub-Last-Rev: 6627c65fb40fad96239edd28bde27a30f9f8f544
GitHub-Pull-Request: golang/go#62647
Reviewed-on: https://go-review.googlesource.com/c/go/+/527976
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
The time granularity on windows is large enough that setting even an
implausibly small timeout still gives ConnectEx enough time to succeed
before the timeout expires. That causes TestDialTimeout to sometimes
flake, because it expects to be able to provoke a timeout using some
nonzero duration.
This change takes a two-pronged approach to address the problem:
1. We can set a deadline on the FD more aggressively. (If the Context
has already expired, or the deadline is already known, we can go ahead
and set it on the fd without waiting for a background goroutine to get
around to it.)
2. We can reintroduce a test hook to ensure that Dial takes a
measurable amount of time before it completes, so that setting an
implausibly short deadline sets that deadline in the past instead of
the future.
Together, these reduce the flake rate on a windows-amd64-longtest
gomote from around 1-in-10 to less than 1-in-2000.
For #62377.
Change-Id: I03975c32f61fffa9f6f84efb3c474a01ac5a0d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/524936
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
When adding MPTCP support to address the proposal #56539, I missed the
GODEBUG setting from Russ Cox's plan:
I am inclined to say that we add MPTCP as an opt-in for a release or
two, and then make it opt-out. There should be a GODEBUG setting (...)
See: https://github.com/golang/go/issues/56539#issuecomment-1309294637
Thanks to andrius4669 for having reported this issue to me.
It makes sense to have this GODEBUG setting not to have to modify
applications to use MPTCP (if available). It can then be useful to
estimate the impact in case we want to switch from opt-in to opt-out
later.
The MPTCP E2E test has been modified to make sure we can enable MPTCP
either via the source code like it was already the case before or with
this environment variable:
GODEBUG=multipathtcp=1
The documentation has been adapted accordingly.
I don't know if it is too late for Go 1.21 but I had to put a version in
the documentation. The modification is small, the risk seems low and
this was supposed to be there from the beginning according to Russ Cox's
specifications. It can also be backported or only be present in the
future v1.22 if it is easier.
Note: I didn't re-open #56539 or open a new one. It is not clear to me
what I should do in this case.
Fixes #56539
Change-Id: I9201f4dc0b99e3643075a34c7032a95528c48fa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/507375
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
Change-Id: I4ec5883fc8713e0f711bb6beff45f426dae8f9f4
GitHub-Last-Rev: 9ea0c1505c2f3974e5d224299db5f888a4cf7618
GitHub-Pull-Request: golang/go#59819
Reviewed-on: https://go-review.googlesource.com/c/go/+/488315
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
Similar to dialMPTCP, this listenMPTCP function is called when the user
has requested MPTCP via SetMultipathTCP in the ListenConfig.
This function falls back to listenTCP on operating systems that do not
support MPTCP or if MPTCP is not supported.
On ListenConfig side, MultipathTCP function can be used to know if the
package will try to use MPTCP or not when Listen is called.
Note that this new listenMPTCP function returns a TCPListener object and
not a new MPTCP dedicated one. The reasons are similar as the ones
explained in the parent commit introducing dialTCP: if MPTCP is used by
default later, Listen will return a different object that could break
existing applications expecting TCPListener.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I010f1d87f921bbac9e157cef2212c51917852353
Reviewed-on: https://go-review.googlesource.com/c/go/+/471137
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
This function is called when the user has requested MPTCP via
SetMultipathTCP in the Dialer.
This new function falls back to dialTCP on operating systems that do not
support MPTCP or if MPTCP is not supported.
On Dialer side, MultipathTCP function can be used to know if the package
will try to use MPTCP or not when Dial is called.
Note that this new dialMPTCP function returns a TCPConn object, like
dialTCP. A new MPTCPConn object using the following composition could
have been returned:
type MPTCPConn struct {
*TCPConn
}
But the drawback is that if MPTCP is used by default one day (see #56539
issue on GitHub), Dial will return a different object: this new
MPTCPConn type instead of the previously expected TCPConn. This can
cause issues for apps checking the returned object.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I0f9b5b81f630b39142bdd553d4f1b4c775f1dff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/471136
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
This new type will be used in the following commits.
The goal is to have a tristate, an enum with three values:
- system default (0)
- enabled
- disabled
The system default value is linked to defaultMPTCPEnabled: disabled by
default for the moment. Users will be able to force enabling/disabling
MPTCP or use the default behaviour.
This work has been co-developped by Gregory Detal
<gregory.detal@tessares.net>.
Updates #56539
Change-Id: I8fa0cad7a18ca967508799fc828ef060b27683d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/477735
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
|
|
Change-Id: I35fcfb2d8cafadca36cffeebe0858973895946d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/451419
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
|
|
CL 107196 introduced a default TCP keepalive interval for Dialer and TCPListener (used by both ListenConfig and ListenTCP). Leaving DialTCP out was likely an oversight.
DialTCP's documentation says it "acts like Dial". Therefore it's natural to also expect DialTCP to enable TCP keepalive by default.
This commit addresses this disparity by moving the enablement logic down to the newTCPConn function, which is used by both dialer and listener.
Fixes #49345
Change-Id: I99c08b161c468ed0b993d1dbd2bd0d7e803f3826
GitHub-Last-Rev: 5c2f1cb0fbc5e83aa6cdbdf3ed4e23419d9bca65
GitHub-Pull-Request: golang/go#56565
Reviewed-on: https://go-review.googlesource.com/c/go/+/447917
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
|
|
Fixes #55301
Change-Id: Ie8abcd383eee9af75038bde908ac638f43d33b7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/444955
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: xie cui <523516579@qq.com>
|
|
CL 410754 introduces a race accessing the global testHookDialTCP hook.
Avoiding this race is difficult, since Dial can return while
goroutines it starts are still running. Add a version of this
hook to sysDialer, so it can be set on a per-test basis.
(Perhaps other uses of this hook should be moved to use the
sysDialer-local hook, but this change fixes the immediate data race.)
For #52173.
Change-Id: I8fb9be13957e91f92919cae7be213c38ad2af75a
Reviewed-on: https://go-review.googlesource.com/c/go/+/410957
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
[This CL is part of a sequence implementing the proposal #51082.
The design doc is at https://go.dev/s/godocfmt-design.]
Run the updated gofmt, which reformats doc comments,
on the main repository. Vendored files are excluded.
For #51082.
Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407
Reviewed-on: https://go-review.googlesource.com/c/go/+/384268
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Dialer.DialContext no longer performs a redundant check on the length
of the fallback slice, because dialParallel already handles the
situation where the fallback slice is empty or nil.
Change-Id: Ibb16f4813fc55dec2939c54c10e665ff35bfe163
Reviewed-on: https://go-review.googlesource.com/c/go/+/387795
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
|
|
The Go standard library retrofitted context support onto existing APIs
using context.Background and later offered variants that directly
supported user-defined context value specification. This commit makes
that behavior clear in documentation and suggests context-aware
alternatives if the user is looking for one.
An example motivation is supporting code for use in systems that expect
APIs to be cancelable for lifecycle correctness or load
shedding/management reasons, as alluded to in
https://blog.golang.org/context-and-structs.
Updates #44143
Change-Id: I2d7f954ddf9b48264d5ebc8d0007058ff9bddf14
Reviewed-on: https://go-review.googlesource.com/c/go/+/296152
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jean de Klerk <deklerk@google.com>
Trust: Jean de Klerk <deklerk@google.com>
Run-TryBot: Jean de Klerk <deklerk@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
If an I/O operation fails because a deadline was exceeded,
return os.ErrDeadlineExceeded. We used to return poll.ErrTimeout,
an internal error, and told users to check the Timeout method.
However, there are other errors with a Timeout method that returns true,
notably syscall.ETIMEDOUT which is returned for a keep-alive timeout.
Checking errors.Is(err, os.ErrDeadlineExceeded) should permit code
to reliably tell why it failed.
This change does not affect the handling of net.Dialer.Deadline,
nor does it change the handling of net.DialContext when the context
deadline is exceeded. Those cases continue to return an error
reported as "i/o timeout" for which Timeout is true, but that error
is not os.ErrDeadlineExceeded.
Fixes #31449
Change-Id: I0323f42e944324c6f2578f00c3ac90c24fe81177
Reviewed-on: https://go-review.googlesource.com/c/go/+/228645
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
|
|
The existing implementation is erroneously assume that having no
deadline in context.Context means that time returned from Deadline
method will have IsZero() == true. But technically speaking this is an
invalid assumption. The context.Context interface specification doesn't
specify what time should be returned from Deadline method when there is
no deadline set. It only specifies that second result of Deadline should
be false.
Fixes #35594
Change-Id: Ife00aad77ab3585e469f15017550ac6c0431b140
Reviewed-on: https://go-review.googlesource.com/c/go/+/207297
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #33743.
Change-Id: I80621321d56b6cf312a86e272800f1ad03c5544c
GitHub-Last-Rev: d91cb3697516ccfc3f956e97837404cbfee5922f
GitHub-Pull-Request: golang/go#33856
Reviewed-on: https://go-review.googlesource.com/c/go/+/191879
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
Fixes #31510
Change-Id: I601d114b617a055380bf3c805e2d9a9b0795b656
Reviewed-on: https://go-review.googlesource.com/c/go/+/175259
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
KeepAlive field used to report the wording "keep-alive period"
which may be misleading. This field does not represent the whole
TCP keepalive time, that is the inactivity period upon which one
endpoint starts probing the other end. But it acctually specifies
the keepalive interval, that is the time between two keepalive
probes.
Fixes #29089
Change-Id: If99b38ba108830d0e5fe527171a2f5c96a3bcde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/155960
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Though there is variation in the spelling of canceled,
cancellation is always spelled with a double l.
Reference: https://www.grammarly.com/blog/canceled-vs-cancelled/
Change-Id: I240f1a297776c8e27e74f3eca566d2bc4c856f2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/170060
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This commit adds a KeepAlive field to ListenConfig and uses it
analogously to Dialer.KeepAlive to set TCP KeepAlives per default on
Accept()
Fixes #23378
Change-Id: I57eaf9508c979e7f0e2b8c5dd8e8901f6eb27fd6
GitHub-Last-Rev: e9e035d53ee8aa3d899d12db08b293f599daecb6
GitHub-Pull-Request: golang/go#31242
Reviewed-on: https://go-review.googlesource.com/c/go/+/170678
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This is just the first step in attempting to make all network connection have
timeouts as a "safe default". TCP keepalives only protect against certain
classes of network and host issues (e.g. server/OS crash), but do nothing
against application-level issues (e.g. an application that accepts connections
but then fails to serve requests).
The actual keep-alive duration (15s) is chosen to cause broken connections
to be closed after 2~3 minutes (depending on the OS, see #23549 for details).
We don't make the actual default value part of the public API for a number of
reasons:
- because it's not very useful by itself: as discussed in #23549 the actual
"timeout" after which the connection is torn down is duration*(KEEPCNT+1),
and we use the OS-wide value for KEEPCNT because there's currently no way
to set it from Go.
- because it may change in the future: if users need to rely on a specific
value they should explicitly set this value instead of relying on the default.
Fixes #23459
Change-Id: I348c03be97588d5001e6de0f377e7a93b51957fd
Reviewed-on: https://go-review.googlesource.com/c/107196
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The Dialer.DualStack field is now meaningless and documented as
deprecated.
To disable fallback, set FallbackDelay to a negative value.
Fixes #22225
Change-Id: Icc212fe07bb69d7651ab81e539b8b3e3d3372fa9
Reviewed-on: https://go-review.googlesource.com/c/146659
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Existing implementation does not provide a way to set options such as
SO_REUSEPORT, that has to be set prior the socket being bound.
New exposed API:
pkg net, method (*ListenConfig) Listen(context.Context, string, string) (Listener, error)
pkg net, method (*ListenConfig) ListenPacket(context.Context, string, string) (PacketConn, error)
pkg net, type ListenConfig struct
pkg net, type ListenConfig struct, Control func(string, string, syscall.RawConn) error
pkg net, type Dialer struct, Control func(string, string, syscall.RawConn) error
Fixes #9661
Change-Id: If4d275711f823df72d3ac5cc3858651a6a57cccb
Reviewed-on: https://go-review.googlesource.com/72810
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Updates #9661
Change-Id: I237e7502cb9faad6dece1e25b1a503739c54d826
Reviewed-on: https://go-review.googlesource.com/115175
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This change clarifies the documentation on Listen and ListenPacket to
avoid unnecessary confusion about how the arguments for the connection
setup functions are used to make connections.
Also replaces "name" or "hostname" with "host name" when the term
implies the use of DNS.
Updates #17613.
Updates #17614.
Updates #17615.
Fixes #17616.
Updates #17738.
Updates #17956.
Change-Id: I0bad2e143207666f2358d397fc076548ee6c3ae9
Reviewed-on: https://go-review.googlesource.com/34876
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This change clarifies the documentation on Dial and its variants to
avoid unnecessary confusion about how the arguments for the connection
setup functions are used to make connections.
Also replaces "name" or "hostname" with "host name" when the term
implies the use of DNS.
Updates #17613.
Fixes #17614.
Fixes #17738.
Fixes #17956.
Updates #18806.
Change-Id: I6adb3f2ae04a3bf83b96016ed73d8e59926f3e8a
Reviewed-on: https://go-review.googlesource.com/34875
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #17615
Change-Id: I7f88c0c6579c79007492e765d1b5ca4f28d19575
Reviewed-on: https://go-review.googlesource.com/45771
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
The argument of the first parameter for connection setup functions on
IP networks must contain a protocol name or number. This change adds
validation for arguments of IP networks to connection setup functions.
Fixes #18185.
Change-Id: I6aaedd7806e3ed1043d4b1c834024f350b99361d
Reviewed-on: https://go-review.googlesource.com/40512
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This will make it possible to use the poller with the os package.
This is a lot of code movement but the behavior is intended to be
unchanged.
Update #6817.
Update #7903.
Update #15021.
Update #18507.
Change-Id: I1413685928017c32df5654ded73a2643820977ae
Reviewed-on: https://go-review.googlesource.com/36799
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Change-Id: I24c6d312f7d0ce52e1958e8031fc8249af0dfca9
Reviewed-on: https://go-review.googlesource.com/34669
Reviewed-by: Minux Ma <minux@golang.org>
|
|
Change-Id: Icef8a21654a248666c684d5b10d0337c544ddb25
Reviewed-on: https://go-review.googlesource.com/34388
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Update #17617.
Change-Id: Ia0bc9954bb914b650b7c7af35ef714ca6b0740b4
Reviewed-on: https://go-review.googlesource.com/34376
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
document about the consecutive dialing introduced in Go 1.5.
If address is resolved to multiple addresses,
Dial will try each address in order until one succeeds.
Deadline is used to try each address (calculated based on
total number of resolved addresses)
Fixes: #17617
Change-Id: I56b6399edb640c8ef507675f98e0bd45a50d4e2d
Reviewed-on: https://go-review.googlesource.com/34176
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The restrictions were already being applied to the IP addresses
received from the host resolver. Apply the same restrictions to
literal IP addresses not passed to the host resolver.
For example, ResolveTCPAddr("tcp4", "[2001:db8::1]:http") used
to succeed and now does not (that's not an IPv4 address).
Perhaps a bit surprisingly,
ResolveTCPAddr("tcp4", "[::ffff:127.0.0.1]:http") succeeds,
behaving identically to ResolveTCPAddr("tcp4", "127.0.0.1:http"), and
ResolveTCPAddr("tcp6", "[::ffff:127.0.0.1]:http") fails,
behaving identically to ResolveTCPAddr("tcp6", "127.0.0.1:http").
Even so, it seems right to match (by reusing) the existing filtering
as applied to addresses resolved by the host C library.
If anyone can make a strong argument for changing the filtering
of IPv4-inside-IPv6 addresses, the fix can be applied to all
the code paths in a separate CL.
Fixes #14037.
Change-Id: I690dfdcbe93d730e11e00ea387fa7484cd524341
Reviewed-on: https://go-review.googlesource.com/32100
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
In general, these functions cannot behave correctly when given a
hostname, because a hostname may represent multiple IP addresses, and
first(isIPv4) chooses at most one.
Updates #9334
Change-Id: Icfb629f84af4d976476385a3071270253c0000b1
Reviewed-on: https://go-review.googlesource.com/31931
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The new Resolver type (a struct) has 9 Lookup methods, all taking a
context.Context.
There's now a new DefaultResolver global, like http's
DefaultTransport and DefaultClient.
net.Dialer now has an optional Resolver field to set the Resolver.
This also does finishes some resolver cleanup internally, deleting
lookupIPMerge and renaming lookupIPContext into Resolver.LookupIPAddr.
The Resolver currently doesn't let you tweak much, but it's a struct
specifically so we can add knobs in the future. Currently I just added
a bool to force the pure Go resolver. In the future we could let
people provide an interface to implement the methods, or add a Timeout
time.Duration, which would wrap all provided contexts in a
context.WithTimeout.
Fixes #16672
Change-Id: I7ba1f886704f06def7b6b5c4da9809db51bc1495
Reviewed-on: https://go-review.googlesource.com/29440
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Callers pass strings sliced as necessary instead of giving
an offset.
Fixes #16350
Change-Id: I7ba896f6ff09e0fd0094ca6c5af5d9a81622f15e
Reviewed-on: https://go-review.googlesource.com/27206
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Also replaces google.com with golang.org in package documentation.
Updates #15228.
Change-Id: I554fa960878fa44557a522635ed412d8d7548d3f
Reviewed-on: https://go-review.googlesource.com/23126
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This fixes change https://go-review.googlesource.com/#/c/23069/, which
assumes all DNS requests are UDP. This is not true -- DNS requests can
be TCP in some cases. See:
https://tip.golang.org/src/net/dnsclient_unix.go#L154
https://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport
Also, the test code added by the above change doesn't actually test
anything because the test uses a faked DNS resolver that doesn't
actually make any DNS queries. I fixed that by adding another test
that uses the system DNS resolver.
Updates #12580
Change-Id: I6c24c03ebab84d437d3ac610fd6eb5353753c490
Reviewed-on: https://go-review.googlesource.com/23101
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The httptrace.ConnectStart and ConnectDone hooks are just about the
post-DNS connection to the host. We were accidentally also firing on
the UDP dials to DNS. Exclude those for now. We can add them back
later as separate hooks if desired. (but they'd only work for pure Go
DNS)
This wasn't noticed earlier because I was developing on a Mac at the
time, which always uses cgo for DNS. When running other tests on
Linux, I started seeing UDP dials.
Updates #12580
Change-Id: I2b2403f2483e227308fe008019f1100f6300250b
Reviewed-on: https://go-review.googlesource.com/23069
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Updates #12580
Change-Id: I9f9578148ef2b48dffede1007317032d39f6af55
Reviewed-on: https://go-review.googlesource.com/22191
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|