locked
emulate udp sendto() and recvfrom() when port C library to WinRT

    Question

  • I have a legacy C library uses UDP to  discover and communicate with a networked device. I am now in the process of porting the library to WinRT. 

    To make as little change as possible , I am just going to emulate sendto() and recvfom() with  WinRT implementation.
    The reason I want minimum change is that the library is a complicated piece of code with years of real user testing/usage, I don't want to break things. 

    emulating sendto() seems very easy. However, for recvfrom(), I will need to set and use the event:

    DatagramSocket.MessageReceived 

    I think this the only supported way of receiving data from UDP and I believe the event is going to be invoked as part of UI thread. Is that correct? 
    The library is a single threaded library with no UI component. Does that mean I will have to change the logic that uses recvfrom() to be tightly integrated with UI code?

    Is there any easy way to emulate recvfom()? I just want a simple way of getting data back from the udp socket. 
    Monday, May 6, 2013 2:28 PM

Answers

  • I think this the only supported way of receiving data from UDP and I believe the event is going to be invoked as part of UI thread. Is that correct? 
    The library is a single threaded library with no UI component. Does that mean I will have to change the logic that uses recvfrom() to be tightly integrated with UI code?

    Is there any easy way to emulate recvfom()? I just want a simple way of getting data back from the udp socket. 

    My application is using UDP and I have my network communication code isolated into a separate assembly with no tight dependency on the UI. Any communication feedback to the UI is done through events that the UI registers with the communications assembly.

    I'm seeing this same kind of question a lot in this forum - Developers have network communication code they want to port that has a serialized flow and they want to just maintain that same architecture. With WinRT async I/O is king and, IMHO, trying to defeat it is going to be more frustration then it is worth. My suggestion is to step back and review how you can abstract your communication logic from you main body of code. Just my $0.02

    • Marked as answer by Jesse Jiang Monday, May 13, 2013 6:32 AM
    Monday, May 6, 2013 3:07 PM