-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Socket API changes mega-issue #33418
Comments
Yet to be approved: #33417 |
Is this ready for implementation? Or is there some kind of obstacle? If not, what would be the level of complexity for a implementation here? |
#40750 implemented the ConnectAsync overloads (not including Happy Eyeballs support). |
I'm wondering about the overloads of SendToAsync, ReceiveFromAsync, and ReceiveMessageFromAsync that omit the SocketFlags argument. It looks to me like we don't actually have overloads of SendAsync/ReceiveAsync that omit the SocketFlags argument. So I'm wondering why we are defining overloads for these other methods. Seems like we should define them for all, or none. @scalablecory Am I missing something here? |
@geoffkizer I believe suggestion came from @wfurt that most of the time you have no flags, but it has been some months. |
I agree with that. But if we're adding overloads without flags, we should add overloads for Send and Receive as well. |
Note, per approval of #43901, we should add the new async overloads to Socket itself, not SocketTaskExtensions. I will update above. |
@geoffkizer the purpose of this issue is to collect already approved API-s. Therefore (if I'm not getting it wrong) you removed approved variants, which are also missing from #43934 since that one only contains unapproved ones. |
…44591) Some `SendReceive` socket tests may be prone to timing issues on CI. This seems to be the root cause of #1712. We need a reliable way to run such tests to unblock the work on new UDP socket API-s in #33418. This PR defines a new `SendReceiveNonParallel` test group, moving `SendToRecvFrom_Datagram_UDP` into that group. Since this is already a significant reorganization, it seemed reasonable to also: - Harmonize naming: all SendReceive test classses are now named either `SendReceive_[SubVariant]` or `SendReceiveNonParallel_[SubVariant]` - Split `SendReceive.cs` into multiple files: - `SendReceive.cs` for the parallel variants - `SendReceiveNonParallel.cs` for the new, non-parallel variants - Rename the non-generic class `SendReceive` to `SendReceiveMisc` (to avoid name collision and confusion with `SendReceive<T>`) and move it to `SendReceiveMisc.cs` - Move `SendReceiveListener` and `SendReceiveUdpClient` to separate files, rename `SendReceiveListener` to `SendReceiveTcpClient`
I am interested in taking up the datagram-related APIs (basically #938's contents) if that's possible. |
@PJB3005 sure, help is always welcome! Note that he async versions have been added in #47229, but the sync Span methods are still unimplemented. #46285 is an example of adding such a sync overload. #46600 is also an interesting problem around that space. Testing can get a bit tricky, but I'm happy to help with that. Feel free to ask any question! |
@geoffkizer @scalablecory is there a reason we did not propose Task-based |
good question, seems like an oversight or possibly the issues were not merged fully. |
Would it be possible for us to split the proposal into several issues? It is easy to lose track of what is already implemented and what is not. |
triage: it seems mostly done. We should check and open new issue for the remaining work. |
Triage: Almost all of the work has been done on this issue. |
This collects all the
Socket
APIs that have been approved: #861 #921 #938. (Edit: Also #43933.)(Edit: removed the async overloads that elide SocketFlags, since this isn't a complete set. See #43934 instead.)
These APIs were approved and implemented in #40750:
These were implemented in #47229:
This was implemented in #46285:
These were implemented in #53340:
The text was updated successfully, but these errors were encountered: