Socket.Poll(μsTimeout, SelectMode.SelectRead) behavior is confusing

[luigiberrettini]

Opened as suggested by @karelz when closing #26209

Microsoft Docs say that Socket.Poll:

• will block execution until the specified time period, measured in microseconds, elapses
• cannot detect certain kinds of connection problems, such as a broken network cable,
  or that the remote host was shut down ungracefully (you must attempt to send or receive data to detect these kinds of errors)
• when used with SelectMode.SelectRead returns:
  • true if Listen(Int32) has been called and a connection is pending
  • true if data is available for reading
  • true if the connection has been closed, reset, or terminated
  • false otherwise

As per my understanding, when the server is up and the connection ok, Socket.Poll with SelectMode.SelectRead should return false immediately.
Unfortunately this doesn't happen and a delay is experienced, due to the timeout expiring: this test fails on the last Assert.Equal() since the actual result is different from the Expected: 0.

It would be great is someone could describe the intended behavior of Socket.Poll with SelectMode.SelectRead:

• returning true only after the timeout elapses and returning false immediately
• returning false only after the timeout elapses and returning true immediately
• returning any result only after the timeout elapses
• returning any result immediately
• other

Is this behavior the same for every SocketType and ProtocolType combination, included the ones used to create the Socket returned by the TcpClient and UdpClient constructors?

I am asking this because UDP is a connectionless protocol therefore a call to Poll could result in a different behavior since there is no connection to be "checked".

[karelz]

Triage: We don't think we will change any APIs behavior even if it is confusing -- documenting the behavior seems like the best choice.

[upsampled]

Any initial progress on the documentation? Or at least a recommendation of another api call that can produce the desired behavior of determining if a:

• socket is readable
• socket is not-readable
• an error occurred: could not determine readability, try again

In a bounded period of time?

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Opened as suggested by @karelz when closing #26209

Microsoft Docs say that Socket.Poll:

• will block execution until the specified time period, measured in microseconds, elapses
• cannot detect certain kinds of connection problems, such as a broken network cable,
  or that the remote host was shut down ungracefully (you must attempt to send or receive data to detect these kinds of errors)
• when used with SelectMode.SelectRead returns:
  • true if Listen(Int32) has been called and a connection is pending
  • true if data is available for reading
  • true if the connection has been closed, reset, or terminated
  • false otherwise

As per my understanding, when the server is up and the connection ok, Socket.Poll with SelectMode.SelectRead should return false immediately.
Unfortunately this doesn't happen and a delay is experienced, due to the timeout expiring: this test fails on the last Assert.Equal() since the actual result is different from the Expected: 0.

It would be great is someone could describe the intended behavior of Socket.Poll with SelectMode.SelectRead:

• returning true only after the timeout elapses and returning false immediately
• returning false only after the timeout elapses and returning true immediately
• returning any result only after the timeout elapses
• returning any result immediately
• other

Is this behavior the same for every SocketType and ProtocolType combination, included the ones used to create the Socket returned by the TcpClient and UdpClient constructors?

I am asking this because UDP is a connectionless protocol therefore a call to Poll could result in a different behavior since there is no connection to be "checked".

Author:	luigiberrettini
Assignees:	liveans
Labels:	documentation, area-System.Net.Sockets
Milestone:	Future