aboutsummaryrefslogtreecommitdiff
path: root/src/net/dial.go
AgeCommit message (Collapse)Author
18 hoursnet: cancel2 should not be shadowWeixie Cui
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>
2025-08-11net: context aware Dialer.Dial functionsMichael Fraenkel
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>
2025-07-22net: correct comment for ListenConfig.ListenPacketLyle Dean
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>
2024-10-21net: document ctx argument to ListenConfig.Listen/ListenPacketIan Lance Taylor
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>
2024-10-01net: document possible networks that can be passed to Controlfavonia
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>
2024-09-03net: enable multipath TCP by default for listenersAperence
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>
2024-02-20net: add KeepAliveConfig and implement SetKeepAliveConfigAndy Pan
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>
2024-01-10net: add available godoc linkcui fliter
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>
2023-09-15net: use bytealg.LastIndexByteStringapocelipes
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>
2023-09-01net: deflake TestDialTimeout on windowsBryan C. Mills
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>
2023-07-11net: mptcp: force using MPTCP with GODEBUGMatthieu Baerts
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>
2023-05-09net: correct Dialer.ControlContext documentationJabar Asadi
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>
2023-03-29net: mptcp: implement listenMPTCPMatthieu Baerts
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>
2023-03-29net: mptcp: implement dialMPTCPMatthieu Baerts
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>
2023-03-24net: add mptcpStatus typeMatthieu Baerts
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>
2022-11-18net: fix typo in ControlContext parameter namesDamien Neil
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>
2022-11-10net: unify TCP keepalive behaviordatabase64128
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>
2022-11-04net: add ControlContext to Dialercuiweixie
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>
2022-06-08net: fix testHookDialTCP raceDamien Neil
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>
2022-04-11all: gofmt main repoRuss Cox
[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>
2022-03-31net: clean up redundant if branch in dialShang Ding
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>
2021-03-11docs: clarify when APIs use context.Background.Matt T. Proud
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>
2020-04-25os, net: define and use os.ErrDeadlineExceededIan Lance Taylor
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>
2019-11-15net: fix improper Context.Deadline usage in DialContextSergey Zagursky
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>
2019-09-02net: document concurrency safety and example for Dialertomocy
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>
2019-05-06net: use same TCP Keep Alive interval between dial and acceptDong-hee Na
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>
2019-04-29net: correct docs of KeepAlive field in Dialer typeBigMikes
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>
2019-04-16all: s/cancelation/cancellation/Josh Bleecher Snyder
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>
2019-04-04net: add KeepAlive field to ListenConfigLeo Antunes
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>
2018-12-03net: enable TCP keepalives by defaultCarlo Alberto Ferraris
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>
2018-11-01net: enable RFC 6555 Fast Fallback by defaultBrad Fitzpatrick
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>
2018-05-30net: add ListenConfig, Dialer.Control to permit socket opts before listen/dialAudrius Butkevicius
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>
2018-05-29net: move dial and listen functions under sysDialer, sysListenerAudrius Butkevicius
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>
2017-06-22net: update documentation on Listen and ListenPacketMikio Hara
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>
2017-06-22net: update documentation on Dial and its variantsMikio Hara
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>
2017-06-14net: clarify Listen on 0.0.0.0 behaviorBrad Fitzpatrick
Fixes #17615 Change-Id: I7f88c0c6579c79007492e765d1b5ca4f28d19575 Reviewed-on: https://go-review.googlesource.com/45771 Reviewed-by: Russ Cox <rsc@golang.org>
2017-04-14net: validate network in Dial{,IP} and Listen{Packet,IP} for IP networksMikio Hara
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>
2017-02-13net: refactor poller into new internal/poll packageIan Lance Taylor
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>
2016-12-23net: Fix spelling of function name in docKevin Burke
Change-Id: I24c6d312f7d0ce52e1958e8031fc8249af0dfca9 Reviewed-on: https://go-review.googlesource.com/34669 Reviewed-by: Minux Ma <minux@golang.org>
2016-12-15net: fix typoKevin Burke
Change-Id: Icef8a21654a248666c684d5b10d0337c544ddb25 Reviewed-on: https://go-review.googlesource.com/34388 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-12-15net: fix consecutive dialing docsIan Lance Taylor
Update #17617. Change-Id: Ia0bc9954bb914b650b7c7af35ef714ca6b0740b4 Reviewed-on: https://go-review.googlesource.com/34376 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-12-14net: document consecutive dialing in net.DialKaviraj
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>
2016-11-11net: apply tcp4/tcp6 restrictions to literals in ResolveTCPAddrRuss Cox
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>
2016-10-25net: add hostname warnings to all first(isIPv4) functions.Paul Marks
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>
2016-09-21net: add Resolver type, Dialer.Resolver, and DefaultResolverBrad Fitzpatrick
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>
2016-08-17net: simplify internal dtoi and xtoi funcsDan Peterson
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>
2016-05-17net: use IPv4/IPv6 reserved address blocks for documentationMikio Hara
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>
2016-05-14net, net/http: don't trace DNS dialsTom Bergan
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>
2016-05-13net, net/http: don't trace UDP dialsBrad Fitzpatrick
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>
2016-04-28net/http, net/http/httptrace: new package for tracing HTTP client requestsBrad Fitzpatrick
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>