-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: