Currently the order of the handshakers is controlled by a single bool(at_start). This doesn't allow for more complex use cases where the handshaker has to be done before tcp connect handshaker for example.
By explicitly adding enums that specify the priority, we allow for a cleaner abstraction for registering handshakers.
Rollforward with TCP connect handshaker again(#29111) after fixing broken internal targets.
The changes needed were just visibility changes to the handshaker and the http_connect_handshaker libraries as they are used internally.
Currently the tcp connect is performed in chttp2_connector before the handshaking is triggered. For
use cases where the application wants to perform business logic before
the tcp connection, this is problematic. By moving the TCP connect into
its own handshaker and registering it by default at the beginning, this
allows applications to add a new handshaker at the beginning allowing
handshaker logic before a TCP connect.
This approach has the advantage of slightly simplifying the logic in
tcp_connect_handshaker and httpcli as tcp_connect/callback can be
removed.
As the TCP connect needs parameters like resolved_addr,
interested_parties, a new struct called connection args is created as a
member for Handshaker Args.
For server handshakers most of the arguments here are not directly
useful, other than the deadline.
* adding a min progress size argument to grpc_endpoint_read
* fix missing argument error
* adding a static_cast
* reverting changes in tcp_posix.cc
* add missing changes to CFStreamEndpointTests.mm
* Refactor end2end tests to exercise each EventEngine
* fix incorrect bazel_only exclusions
* Automated change: Fix sanity tests
* microbenchmark fix
* sanitize, fix iOS flub
* Automated change: Fix sanity tests
* iOS fix
* reviewer feedback
* first pass at excluding EventEngine test expansion
Also caught a few cases where we should not test pollers, but should
test all engines. And two cases where we likely shouldn't be testing
either product.
* end2end fuzzers to be fuzzed differently via EventEngine.
* sanitize
* reviewer feedback
* remove misleading comment
* reviewer feedback: comments
* EE test_init needs to play with our build system
* fix golden file test runner
Co-authored-by: drfloob <drfloob@users.noreply.github.com>
* Fix all lint errors in repo.
* Use strict buildifier by default
* Whoops. That file does not exist
* Attempt fix to buildifier invocation
* Add missing copyright
Motivation: In debug builds, `DebugOnlyTraceFlag`s are hard-coded to be
disabled. This results in unreachable code paths that the compiler can
detect, which prevent us from enabling `-Wunreachable-code-aggressive`
on the builds.
This work aims to reduce the number of places that switch on
`trace_flag.enabled`.
It is not possible for such a function to be implemented in a way that
is understood by annotalysis. Mark it deprecated and replace instances
of its use with direct mutex/condvar usage.
Add a bunch of missing thread safety annotations while I'm here.
* Add Python mTLS greeter example (#40)
* Revert "Add Python mTLS greeter example (#40)"
This reverts commit 383c247775.
* Postpone EVP_cleanup until after last server_ssl_test run completes.
* Fix readahead_hs_server_ssl
* Clang fixes and client side initialization fix.
* Comment out EVP_cleanup on client side.
* remove TLS 1.3 ciphers'
* change to using server0 credentials
* log what TLS method is used'
* check compatibility of private key and cert
* Try allowing server to use all ciphers.
* Add logging for test server.
* Fix private key check logging.
* add include for tracing
* define tsi_tracing_enabled flag
* rename tsi_tracing_enabled flag
* try printing bytes to send to peer
* Add automatic curve selection
* Remove logging from SSL transport security
* Add back TLS 1.3 ciphersuites.
Co-authored-by: Ryan Kim <Ryanfsdf@users.noreply.github.com>
The urgent argument is a platform-specific flag that leaked into the (ideally) platform-independent HTTP/2 transport layer. In an effort to clean up the cross-platform API surface, it would be helpful if we can remove this argument from the TCP Read api without losing the performance optimization that was introduced along with it (see #18240).
Yijie Ma