Add DiagnosticServer runtime TCP support. #48154
Conversation
lateralusX
force-pushed
the
lateralusX/add-eventpipe-tcp-support
branch
3 times, most recently
from
130296b
to
2c7191c
Compare
|
Tagging subscribers to this area: @tommcdon Issue DetailsRestructuring of existing DiagnosticServer PAL code into following: Win32 named pipe support for local IPC is renamed to ds-ipc-pal-namedpipe.h|c By default all builds and run as before, win32 uses named pipe for local IPC and none Windows uses Unix domain sockets. This PR extends support in ds-ipc-pal-socket.* to also support TCP (IPv4/IPv6) transports cross platform, meaning that its possible to configure and compile DiagnosticServer using TCP instead of NamedPipe/Unix Domain Sockets for both listener and connect scenarios. TCP support will be needed in order to support EventPipe on remote targets like mobile, but then most likely only supporting the connect scenario (no listener support) and only for builds used during development/testing and profiling work, but all is completely configurable.
|
|
/cc @josalem |
lateralusX
force-pushed
the
lateralusX/add-eventpipe-tcp-support
branch
from
2c7191c
to
21e5211
Compare
lateralusX
changed the title
lateralusX
requested review from
CoffeeFlux,
lambdageek,
marek-safar and
vargaz
as code owners
lateralusX
force-pushed
the
lateralusX/add-eventpipe-tcp-support
branch
from
998f795
to
04ff29c
Compare
Regarding EINTR, the original Unix Domain Socket implementation didn't have this either, so that carried over into this implementation. A lot of the calls will be retried at some point, but agree that we should add checks and retry just to be clear. It will be easy done now as well since all send/recv/poll/connect operations are part of their own methods, @josalem, any thoughts? |
|
Looking into adding EINTR handling into this PR. |
|
@lambdageek Added retry logic for syscalls documented to return EINTR. |
Yes, so right now we can only have NamedPipe+UDS support or TCP, not possible to combine them. Default is what we have today, NamedPipe +UDS. In order switch to TCP, you need to define CMake build flag, FEATURE_PERFTRACING_PAL_TCP. |
Newline added by Mono logging API, so needed to make source free of newline. Since newline is needed by CoreClr, add it as part of DS logging macro's.
Move verbose logging into debug log level. Reduce warnings in connection time out scenario, could be very frequent for TCP/IP where no endpoint is up and listening. Restored error handling in ds_ipc_stream_factory_get_next_available_stream.
lateralusX
force-pushed
the
lateralusX/add-eventpipe-tcp-support
branch
from
9a7d95f
to
aea1c2f
Compare
ghost
locked as resolved and limited conversation to collaborators
Restructuring of existing DiagnosticServer PAL code into following:
Win32 named pipe support for local IPC is renamed to ds-ipc-pal-namedpipe.h|c
Unix domain socket support for local IPC is part of more generic socket support ds-ipc-pal-socket.h|c
By default all builds and run as before, win32 uses named pipe for local IPC and none Windows uses Unix domain sockets.
This PR extends support in ds-ipc-pal-socket.* to also support TCP (IPv4/IPv6) transports cross platform, meaning that its possible to configure and compile DiagnosticServer using TCP instead of NamedPipe/Unix Domain Sockets for both listener and connect scenarios. TCP support will be needed in order to support EventPipe on remote targets like mobile, but then most likely only supporting the connect scenario (no listener support) and only for builds used during development/testing and profiling work, but all is completely configurable.
PR adds a couple of build config flags that could be used:
FEATURE_PERFTRACING_PAL_TCP
Enables TCP/IP support in diagnostics server on all platforms, instead of default named pipe/unix domain socket support.
FEATURE_PERFTRACING_DISABLE_CONNECT_PORTS
Disables ability for diagnostic server to connect against remote ports.
FEATURE_PERFTRACING_DISABLE_LISTEN_PORTS
Disables ability for diagnostic server to listen on local ports.
By default none of the above config flags are used by this PR, but for some Mono runtime workloads we will need TCP/IP and connect ports (listen ports can be disabled).