Berkeley Socket facade for WinRT Networking plausibility?

35
votes

This is a copy of a post I've sent to the ZeroMQ mailing list. However, the question is raises it not specific to ZeroMQ, but more generally regarding the need for a 'mapping' layer over the networking functionality provided in WinRT to provide a more normal 'Berkeley Socket facade' for C++ code when compiling against WinRT:

Hi all, I've used ZeroMQ in a mobile app (see http://www.ibuzzedfirst.com ) previously, for the iPhone and Android versions, as those platforms support native/C++/Socket development, and therefore ZeroMQ.

For the WindowsPhone 7.5 (OS 7.1) version, I had to re-implement any required ZeroMQ functionality from scratch, as WinPhone 7.5 only supports C#, not C++ (it's effectively a C# Silverlight App). Also, WinPhone 7.5 only provides its own 'version' of Socket support ( http://msdn.microsoft.com/en-us/library/sb27wehh%28v=vs.95%29.aspx ) which only support Async versions of functions, e.g. ConnectAsync, SendAync, ReceiveAsync etc. However, the lack of C++ made this a moot point.

As such, for the WindowsPhone 7.5 version, I restricted the app to 'client' (Contestant) functionalty only, and didn't implement the 'server' (Quiz Master) part. This was because the client part of the app only sends and receives requests, replies and subscriptions to the server, whereas the server utilises the inherent multi-threaded multi-user functionality of ZeroMQ. It was (relatively) simple to recreate the ZeroMQ transport protocol/headers for client use, and use the WindowsPhone Socket support to provide comms.

Ok, now I'm looking at porting the app to WinRT on Windows 8. (The desktop/tablet version first - the Windows Phone 8 RT SDK isn't out yet, but will be similar). The good news is that C++ is supported in WinRT, yay! (Actually, it still isn't that simple, when writing C# only WinRT apps, you can compile for 'AnyCPU', as soon as you include a C++ portion, you have to build 3 different versions - x86/Win32, x64, and ARM versions, but that's a different problem).

Unfortunately though, like Windows 7/8 Phone, WinRT does NOT support 'normal' Berkeley Socket access, but instead offers its own 'version' of Socket programming, with discrete classes for different socket scenarios, e.g. StreamSocket for a connecting TCP client ( http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.streamsocket.aspx#methods ), StreamSocketListener for a bindable TCP server ( http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.streamsocketlistener.aspx#methods ), and DatagramSocket / DatagramSocketListener for the UDP versions. Furthermore, only async versions of all the methods are provided.

So it looks like, to get ZeroMQ to compile sucessfully on WinRT, I'm going to have to write a Facade layer that provdes a Berkeley Socket-like C++ interface, and underneath performs the necessary mapping to the version of Socket programming provided by WinRT.

Has anyone else started this journey or written a similar facade? Interested to hear everyone's thoughts, especailly as WinRT looks to quite a 'big thing'!

2
socketswindows-8microsoft-metrowindows-runtimezeromq
I've just realised this is an even bigger job to get going, as ZeroMQ uses the C Runttime function _beginthreadex() to create threads as required. WinRT doesn't support direct creation and manipulation of threads either ( msdn.microsoft.com/en-us/library/windows/apps/… msdn.microsoft.com/en-us/library/windows/apps/hh701576.aspx ), and only supports Task.Run() and RunAsync() style background processing. Getting ZeroMQ to work in WinRT wouldn't be trivial. – yorkshirespud
Hmm, maybe the threading isn't too much of a problem, other people have already looked at this, e.g. blogs.msdn.com/b/shawnhar/archive/2012/03/12/… to shim pseduo-Create Thread calls into Metro apps – yorkshirespud
One final note - all the above lack of native C/C++ WinSock applies to Windows 8 RT (Desktop/Tablet). It turns out that only for Windows 8 Phone RT (Win 8 Phones) - C/C++ WinSock is fully supported. So you can make native WinSock calls on a in Win PRT, but NOT desktop Win RT. Easier to develop WinPho8 network apps than WinRT! – yorkshirespud
The lack of C library support in WinRT makes writing an adapter for C/C++ code that needs system codes rather daunting. You're effectively writing adapters for multiple system calls. Would the opposite approach be more feasible: port ZeroMQ to WinRT? – Christopher Stevenson
There's this article on arstechnica which goes some way to explaining things (arstechnica.com/features/2012/10/…). In talking about this with various colleagues it seems there is some doubt if that article is completely correct, but it is still a useful read. The bit about all I/O being asynchronous means using call backs for everything. That's seems like being a loooong way from the programming model of ZeroMQ and Berkley sockets! – bazza

2 Answers

2
votes

Though its far from complete or correct and has lots of bugs, but I have started this project here https://winrtsock.codeplex.com. Have not implemented any listen/accept as of yet

1
votes

You might consider something like ACE. It provides slightly higher-level abstractions over sockets, and supports older windows embedded OSs such as WinCE and the like. It's open source, so you can try it out, hack it up to make it work and contribute back. Alternatively you can contact one of several commercial organizations or people that offer support and contract the work.