fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater #1816

jamdavi · 2021-03-08T18:37:44Z

The edge client HSM provider uses UnixDomainSockets (UDS) for communication. Before .NET 2.1 to implement a Unix Socket you had to create your own class to do so. Since 2.1 there has been a native UnixDomainSocketEndPoint class in the runtime.

In 2.1 and 3.1 there is no issue. However in 5.0 there are some changes to the way the Socket class handles the native UnixDomainSocketEndPoint class. I didn't dig down extremely deep, but I suspect it's due to the way the endpoint handles the SocketAddress and the string manipulation there seeing as how there is a specific implementation for Windows and for Unix.

Tested On Windows Containers

dotnetcore 2.1
dotnetcore 3.1
.NET 5.0

…versions to use the correct class

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs

drwill-ms

I don't understand how this fixes the issue. The only difference in the two code paths seems to be a fully-qualified namespace, which is already in usings. Is there a different type of the same name in a different namespace?

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs

jamdavi · 2021-03-08T23:12:29Z

I don't understand how this fixes the issue. The only difference in the two code paths seems to be a fully-qualified namespace, which is already in usings. Is there a different type of the same name in a different namespace?

Correct, the unqualified class is an IoT Hub implementation of this class that is needed for CLR versions less than core 2.1.

This change uses the supplied .NET framework implementation for the later versions.

bikamani · 2021-03-09T01:37:02Z

I don't understand how this fixes the issue. The only difference in the two code paths seems to be a fully-qualified namespace, which is already in usings. Is there a different type of the same name in a different namespace?

Correct, the unqualified class is an IoT Hub implementation of this class that is needed for CLR versions less than core 2.1.

This change uses the supplied .NET framework implementation for the later versions.

Got it, I got confused with the naming (UnixDomainSocketEndPoint) earlier as well. I can see adding a comment/renaming IoT Hub implementation for versions less than core 2.1 would be useful.

jamdavi · 2021-03-09T16:09:29Z

/azp run

azure-pipelines · 2021-03-09T16:09:40Z

Azure Pipelines successfully started running 1 pipeline(s).

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs

jamdavi · 2021-03-09T18:31:50Z

/azp run

azure-pipelines · 2021-03-09T18:32:01Z

Azure Pipelines successfully started running 1 pipeline(s).

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs

jamdavi · 2021-03-09T19:02:42Z

/azp run

azure-pipelines · 2021-03-09T19:02:52Z

Azure Pipelines successfully started running 1 pipeline(s).

* fix: samples readme links were out-of-date (#1784) * fix: samples arguments and remove 1 more dead link (#1785) * fix(readme): Update the location of ConsoleEventListener in our readme * doc(service-client) - Updating readme (#1799) * fix(doc): Update amqp transport exception doc to have detailed description for quota exceeded error mapping * feature(device-client): Make the DeviceClient and ModuleClient extensible (#1802) * doc(service-client): Added extra comments to clarify true and false in dispose (#1805) * feature,fix (device-client) Handle Twin failures using Amqp (#1796) * fix(iot-service): Update xml comments for ServiceClient * fix(iot-device): Update MqttTransportHandler to not use SemaphoreSlim.WaitAsync(TimeSpan, CancellationToken) * fix(iot-device): Update dotnetty task calls to use ConfigureAwait(true) * fix(iot-device): Fix MqttTransportHandler to not await on user supplied C2D callback * IoTHub Exception for Get and Patch Twin failures (#1815) * fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater (#1816) * UnixDomainSocketEndPoint has been standard since 2.1. Allowing later versions to use the correct class The edge client HSM provider uses UnixDomainSockets (UDS) for communication. Before .NET 2.1 to implement a Unix Socket you had to create your own class to do so. Since 2.1 there has been a native UnixDomainSocketEndPoint class in the runtime. In 2.1 and 3.1 there is no issue. However in 5.0 there are some changes to the way the Socket class handles the native UnixDomainSocketEndPoint class. I didn't dig down extremely deep, but I suspect it's due to the way the endpoint handles the SocketAddress and the string manipulation there seeing as how there is a specific implementation for Windows and for Unix. * feat(e2e) - Enabling soft delete when creating keyvaults (#1820) * fix(e2e) - Change event logging to opt in to specific events only. (#1824) * (service-client): Design for IoT hub AAD authentication * (service-client: Refactor and add implementation for token credential input) (#1781) * (service-client): Refactor and add sas credential (#1786) * (service-client): Add constructors in service client to accept aad and sas tokens. (#1787) * (service-client): Add constructors in registry manager to accept aad and sas tokens. (#1788) * (service-client): Add constructors in job client to accept aad and sas tokens. (#1789) * (service-client): Add constructors to accept aad and sas tokens for digital twins client. (#1790) * fix(service-client): Support for AzureSasCredential for a better user experience (#1797) * doc(service-client): Update readme about the differnt client and operations (#1798) * tests(service-client): E2E tests for aad auth on all our clients (#1800) * test(service-client): Adding e2e tests for sas credential auth for IoT hub. (#1806) * feature(service-client): Adding chaching for aad tokens. (#1807) * fix(service-client)- Add IoT hub token scope. (#1812) Co-authored-by: David R. Williamson <drwill@microsoft.com> Co-authored-by: Abhipsa Misra <abhipsa.misra@microsoft.com> Co-authored-by: bikamani <41314966+bikamani@users.noreply.github.com> Co-authored-by: jamdavi <73593426+jamdavi@users.noreply.github.com>

…ter (#1816) * UnixDomainSocketEndPoint has been standard since 2.1. Allowing later versions to use the correct class The edge client HSM provider uses UnixDomainSockets (UDS) for communication. Before .NET 2.1 to implement a Unix Socket you had to create your own class to do so. Since 2.1 there has been a native UnixDomainSocketEndPoint class in the runtime. In 2.1 and 3.1 there is no issue. However in 5.0 there are some changes to the way the Socket class handles the native UnixDomainSocketEndPoint class. I didn't dig down extremely deep, but I suspect it's due to the way the endpoint handles the SocketAddress and the string manipulation there seeing as how there is a specific implementation for Windows and for Unix.

…and greater (#1816)" This reverts commit 50e77bb.

* fix: samples readme links were out-of-date (#1784) * fix: samples arguments and remove 1 more dead link (#1785) * fix(readme): Update the location of ConsoleEventListener in our readme * doc(service-client) - Updating readme (#1799) * fix(doc): Update amqp transport exception doc to have detailed description for quota exceeded error mapping * feature(device-client): Make the DeviceClient and ModuleClient extensible (#1802) * doc(service-client): Added extra comments to clarify true and false in dispose (#1805) * feature,fix (device-client) Handle Twin failures using Amqp (#1796) * fix(iot-service): Update xml comments for ServiceClient * fix(iot-device): Update MqttTransportHandler to not use SemaphoreSlim.WaitAsync(TimeSpan, CancellationToken) * fix(iot-device): Update dotnetty task calls to use ConfigureAwait(true) * fix(iot-device): Fix MqttTransportHandler to not await on user supplied C2D callback * IoTHub Exception for Get and Patch Twin failures (#1815) * fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater (#1816) * UnixDomainSocketEndPoint has been standard since 2.1. Allowing later versions to use the correct class The edge client HSM provider uses UnixDomainSockets (UDS) for communication. Before .NET 2.1 to implement a Unix Socket you had to create your own class to do so. Since 2.1 there has been a native UnixDomainSocketEndPoint class in the runtime. In 2.1 and 3.1 there is no issue. However in 5.0 there are some changes to the way the Socket class handles the native UnixDomainSocketEndPoint class. I didn't dig down extremely deep, but I suspect it's due to the way the endpoint handles the SocketAddress and the string manipulation there seeing as how there is a specific implementation for Windows and for Unix. * feat(e2e) - Enabling soft delete when creating keyvaults (#1820) * fix(e2e) - Change event logging to opt in to specific events only. (#1824) * (service-client): Design for IoT hub AAD authentication * (service-client: Refactor and add implementation for token credential input) (#1781) * (service-client): Refactor and add sas credential (#1786) * (service-client): Add constructors in service client to accept aad and sas tokens. (#1787) * (service-client): Add constructors in registry manager to accept aad and sas tokens. (#1788) * (service-client): Add constructors in job client to accept aad and sas tokens. (#1789) * (service-client): Add constructors to accept aad and sas tokens for digital twins client. (#1790) * fix(service-client): Support for AzureSasCredential for a better user experience (#1797) * doc(service-client): Update readme about the differnt client and operations (#1798) * tests(service-client): E2E tests for aad auth on all our clients (#1800) * test(service-client): Adding e2e tests for sas credential auth for IoT hub. (#1806) * feature(service-client): Adding chaching for aad tokens. (#1807) * fix(service-client)- Add IoT hub token scope. (#1812) Co-authored-by: David R. Williamson <drwill@microsoft.com> Co-authored-by: Abhipsa Misra <abhipsa.misra@microsoft.com> Co-authored-by: bikamani <41314966+bikamani@users.noreply.github.com> Co-authored-by: jamdavi <73593426+jamdavi@users.noreply.github.com>

…ter (#1816) * UnixDomainSocketEndPoint has been standard since 2.1. Allowing later versions to use the correct class The edge client HSM provider uses UnixDomainSockets (UDS) for communication. Before .NET 2.1 to implement a Unix Socket you had to create your own class to do so. Since 2.1 there has been a native UnixDomainSocketEndPoint class in the runtime. In 2.1 and 3.1 there is no issue. However in 5.0 there are some changes to the way the Socket class handles the native UnixDomainSocketEndPoint class. I didn't dig down extremely deep, but I suspect it's due to the way the endpoint handles the SocketAddress and the string manipulation there seeing as how there is a specific implementation for Windows and for Unix.

* fix: samples readme links were out-of-date (#1784) * fix: samples arguments and remove 1 more dead link (#1785) * fix(readme): Update the location of ConsoleEventListener in our readme * doc(service-client) - Updating readme (#1799) * fix(doc): Update amqp transport exception doc to have detailed description for quota exceeded error mapping * feature(device-client): Make the DeviceClient and ModuleClient extensible (#1802) * doc(service-client): Added extra comments to clarify true and false in dispose (#1805) * feature,fix (device-client) Handle Twin failures using Amqp (#1796) * fix(iot-service): Update xml comments for ServiceClient * fix(iot-device): Update MqttTransportHandler to not use SemaphoreSlim.WaitAsync(TimeSpan, CancellationToken) * fix(iot-device): Update dotnetty task calls to use ConfigureAwait(true) * fix(iot-device): Fix MqttTransportHandler to not await on user supplied C2D callback * IoTHub Exception for Get and Patch Twin failures (#1815) * fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater (#1816) * UnixDomainSocketEndPoint has been standard since 2.1. Allowing later versions to use the correct class The edge client HSM provider uses UnixDomainSockets (UDS) for communication. Before .NET 2.1 to implement a Unix Socket you had to create your own class to do so. Since 2.1 there has been a native UnixDomainSocketEndPoint class in the runtime. In 2.1 and 3.1 there is no issue. However in 5.0 there are some changes to the way the Socket class handles the native UnixDomainSocketEndPoint class. I didn't dig down extremely deep, but I suspect it's due to the way the endpoint handles the SocketAddress and the string manipulation there seeing as how there is a specific implementation for Windows and for Unix. * feat(e2e) - Enabling soft delete when creating keyvaults (#1820) * fix(e2e) - Change event logging to opt in to specific events only. (#1824) * (service-client): Design for IoT hub AAD authentication * (service-client: Refactor and add implementation for token credential input) (#1781) * (service-client): Refactor and add sas credential (#1786) * (service-client): Add constructors in service client to accept aad and sas tokens. (#1787) * (service-client): Add constructors in registry manager to accept aad and sas tokens. (#1788) * (service-client): Add constructors in job client to accept aad and sas tokens. (#1789) * (service-client): Add constructors to accept aad and sas tokens for digital twins client. (#1790) * fix(service-client): Support for AzureSasCredential for a better user experience (#1797) * doc(service-client): Update readme about the differnt client and operations (#1798) * tests(service-client): E2E tests for aad auth on all our clients (#1800) * test(service-client): Adding e2e tests for sas credential auth for IoT hub. (#1806) * feature(service-client): Adding chaching for aad tokens. (#1807) * fix(service-client)- Add IoT hub token scope. (#1812) Co-authored-by: David R. Williamson <drwill@microsoft.com> Co-authored-by: Abhipsa Misra <abhipsa.misra@microsoft.com> Co-authored-by: bikamani <41314966+bikamani@users.noreply.github.com> Co-authored-by: jamdavi <73593426+jamdavi@users.noreply.github.com>

UnixDomainSocketEndPoint has been standard since 2.1. Allowing later …

39006e9

…versions to use the correct class

jamdavi requested review from abhipsaMisra, azabbasi, barustum, bikamani, drwill-ms, timtay-microsoft and vinagesh as code owners March 8, 2021 18:37

drwill-ms reviewed Mar 8, 2021

View reviewed changes

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs Show resolved Hide resolved

drwill-ms reviewed Mar 8, 2021

View reviewed changes

abhipsaMisra reviewed Mar 8, 2021

View reviewed changes

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs Outdated Show resolved Hide resolved

abhipsaMisra approved these changes Mar 8, 2021

View reviewed changes

Adding comments

49e1777

barustum reviewed Mar 9, 2021

View reviewed changes

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs Outdated Show resolved Hide resolved

abhipsaMisra mentioned this pull request Mar 9, 2021

[Bug Report] : Edge module is unable to send the updated sas token to edge hub #1810

Closed

Simplifying enpoint switching

95f3938

bikamani approved these changes Mar 9, 2021

View reviewed changes

#if is not a scope...

99238cd

drwill-ms reviewed Mar 9, 2021

View reviewed changes

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs Outdated Show resolved Hide resolved

drwill-ms reviewed Mar 9, 2021

View reviewed changes

iothub/device/src/ModernDotNet/HsmAuthentication/Transport/HttpUdsMessageHandler.cs Outdated Show resolved Hide resolved

drwill-ms approved these changes Mar 9, 2021

View reviewed changes

Comment style and FQ namespace

1885e0a

jamdavi merged commit 2e71c39 into master Mar 9, 2021

jamdavi deleted the jamdavi/UnixDomainSocketFix branch March 9, 2021 19:57

abhipsaMisra added a commit that referenced this pull request Mar 19, 2021

Revert "fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 …

822250a

…and greater (#1816)" This reverts commit 50e77bb.

abhipsaMisra added a commit that referenced this pull request Mar 19, 2021

Revert "fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 …

459bde6

…and greater (#1816)" This reverts commit 50e77bb.

jamdavi mentioned this pull request Mar 19, 2021

release: Bump versions for latest release #1842

Merged

abhipsaMisra added a commit that referenced this pull request Mar 19, 2021

Revert "fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 …

688c53b

…and greater (#1816)" This reverts commit 50e77bb.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater #1816

fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater #1816

jamdavi commented Mar 8, 2021

drwill-ms left a comment

jamdavi commented Mar 8, 2021 •

edited

bikamani commented Mar 9, 2021 •

edited

jamdavi commented Mar 9, 2021

azure-pipelines bot commented Mar 9, 2021

jamdavi commented Mar 9, 2021

azure-pipelines bot commented Mar 9, 2021

jamdavi commented Mar 9, 2021

azure-pipelines bot commented Mar 9, 2021

fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater #1816

fix(edge): UnixDomainSocketEndPoint is available in .NET 2.1 and greater #1816

Conversation

jamdavi commented Mar 8, 2021

Tested On Windows Containers

drwill-ms left a comment

Choose a reason for hiding this comment

jamdavi commented Mar 8, 2021 • edited

bikamani commented Mar 9, 2021 • edited

jamdavi commented Mar 9, 2021

azure-pipelines bot commented Mar 9, 2021

jamdavi commented Mar 9, 2021

azure-pipelines bot commented Mar 9, 2021

jamdavi commented Mar 9, 2021

azure-pipelines bot commented Mar 9, 2021

jamdavi commented Mar 8, 2021 •

edited

bikamani commented Mar 9, 2021 •

edited