Harmonize ReceiveMessageFrom tests and bring them back to Inner Loop

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.

[antonfirsov]

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replace the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The variants of the new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serve as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These 2 were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier to follow and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[ghost]

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

Issue Details

---

Contributes to #41502 and #43845 by making the tests for ReceiveMessageFrom easier maintain and extend, harmonizing them under the SocketTestHelper infrastructure similarly to the code in SendReceive.cs

All old ReceiveMessageFrom.cs and ReceiveMessageFromAsync.cs tests have been refactored to ReceiveMessageFrom<T> and subclasses:

• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_Success replaces the following old tests:
  ReceiveMessageFrom.Success, ReceiveMessageFrom.Success_IPv6, ReceiveMessageFrom.Success_APM, ReceiveMessageFromAsync.ReceiveSentMessages_Tasks_Success
• The new test ReceiveMessageFrom<T>.ReceiveSentMessages_ReuseEventArgs_Success serves as a replacement for:
  ReceiveMessageFrom.Success_EventArgs, ReceiveMessageFromAsync.ReceiveSentMessages_SocketAsyncEventArgs_Success. These were more or less duplicates, except that latter served as a regression test for Fix lifetime handling of ReceiveMessageFromAsync buffer on Windows corefx#22012 by setting the buffer multiple times. The new test case keeps exercising this behavior. (Note: I also tried to alter between different buffer modes using the same SocketAsyncEventArgs instance, which made me to discover ReceiveMessageFrom does not work correctly on Linux after altering BufferList to a single buffer #46860.)

All the ReceiveMessageFrom tests are brought back to inner loop, since there's no reason to keep them in outer loop. They were pushed out in dotnet/corefx#11341 as part of an umbrella operation to stabilize networking tests. I'm not aware of any instabilities caused by ReceiveMessageFrom runs.

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[geoffkizer]

LGTM -- one minor comment above

[geoffkizer]

This is nice to see, thanks.