[boost] ASIO does not fully support Windows Runtime (WinRT), and a suggestion for providing support

[Moshe Rubin]

While attempting to port filesystem to Windows Phone 8.1, I encountered some issues with the WinRT portions of ASIO. Examining the Boost code shows that ASIO does not fully support WinRT. Examples are that the acceptor implementation for WinRT #includes the null_socket_service class in socket_acceptor_service.hpp, rendering it unsupported. In addition, there is no counterpart in WinRT to WinSock's select() function, so there is no way to call select() off of a WinRT socket object.

I would therefore like to briefly summarize what my company's needs are, what problems I've encountered, and a suggested solution for having ASIO support WinRT.

Here are our corporate library's (let's call it CORLIB) needs:

(*) Our goal is to build our Boost-based library (i.e., CORLIB) for Windows Phone 8.1.
(*) CORLIB refers to Boost sockets in a cross-platform fashion (e.g., using the basic_stream_socket class as an abstraction via boost::asio::ip::tcp::socket).
(*) CORLIB uses the boost::asio::ip::tcp::acceptor object in portions of its code.
(*) CORLIB also calls the bind() socket function
(*) CORLIB uses the BSD/Winsock functions select() and bind(), among other functions, to implement its logic

Here are the problems:

(*) The socket_acceptor_service class #includes null_socket_service.hpp to implement the acceptor object for WinRT. In other words, the acceptor object is not implemented for WinRT.
(*) The winrt_ssocket_service_base class does not implement the listen() function, something that must be implemented to support the acceptor object.
(*) The winrt_ssocket_service class implements native_handle_type as Windows::Networking::Sockets::StreamSocket^. There is no WinRT analog for the BSD/WinSock select() function, so CORLIB has no way of performing a select on the StreamSocket object. Since select() is critical to CORLIB, StreamSocket^ is unacceptable.

We believe that winrt_ssocket_service must be implemented using WinSock (almost completely supported by Windows Phone 8.1) rather than Windows::Networking::Sockets, because the select() function is unimplementable using the WinRT hierarchy.

We therefore propose creating a new socket service class for WinRT (we will refer to this new service class as winrt_winsock_socket_service) . This new service will be similar to reactive_socket_service: the stream_socket_service.hpp include file shows the following:

#if defined(BOOST_ASIO_WINDOWS_RUNTIME)
# include <boost/asio/detail/winrt_ssocket_service.hpp>
#elif defined(BOOST_ASIO_HAS_IOCP)
# include <boost/asio/detail/win_iocp_socket_service.hpp>
#else
# include <boost/asio/detail/reactive_socket_service.hpp>
#endif

Since we want to return to WinSock-based sockets for WinRT, we therefore want to model the Winsock-based WinRT implementation on reactive_socket_service, making changes for WinRT when necessary. Because Windows Phone 8.1 supports Winsock2, including bind(), listen(), and select(), we should be able to support WinRT via WinSock. This class will not make any use of WinRT's new socket classes.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Niall Douglas]

On 15 Jan 2015 at 10:32, Moshe Rubin wrote:

> I would therefore like to briefly summarize what my company's needs are,
> what problems I've encountered, and a suggested solution for having ASIO
> support WinRT.

> [snip]

> We therefore propose creating a new socket service class for WinRT (we
> will refer to this new service class as winrt_winsock_socket_service) .
> This new service will be similar to reactive_socket_service: the
> stream_socket_service.hpp include file shows the following:

Instead of publically telling everyone what you think Chris hasn't
done and what he should do, you might consider approaching him with a
view to contracting him at his hourly rate to improve WinRT support
in ASIO, or even just asking him how you can best help him to make
this happen.

Instead of writing to this list, I'd also start with logging an issue
at https://github.com/chriskohlhoff/asio/issues, and instead of the
commanding and impatient tone you might try indicating you are
willing to pay Chris for the improvements according to how Chris
thinks they should be implemented. If you're lucky, Chris may create
time for your improvements sooner rather than later. He may even do
it for free.

You can of course also do the work yourself and send him a pull
request on github, but I've noticed he usually won't merge any large
new pull requests he hasn't solicited. I assume they conflict with
his other feature work branches, or don't have the quality Chris is
looking for.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/

[Edward Diener]

On 1/15/2015 7:58 AM, Niall Douglas wrote:
> On 15 Jan 2015 at 10:32, Moshe Rubin wrote:
>
>> I would therefore like to briefly summarize what my company's needs are,
>> what problems I've encountered, and a suggested solution for having ASIO
>> support WinRT.
>> [snip]
>> We therefore propose creating a new socket service class for WinRT (we
>> will refer to this new service class as winrt_winsock_socket_service) .
>> This new service will be similar to reactive_socket_service: the
>> stream_socket_service.hpp include file shows the following:
>
> Instead of publically telling everyone what you think Chris hasn't
> done and what he should do, you might consider approaching him with a
> view to contracting him at his hourly rate to improve WinRT support
> in ASIO, or even just asking him how you can best help him to make
> this happen.

You are badly misinterpreting the OP. Why I do not know ? The OP was
just bringing up a matter that concerned them. It did not in any way
malign Chris or anyone connected with ASIO.

>
> Instead of writing to this list, I'd also start with logging an issue
> at https://github.com/chriskohlhoff/asio/issues, and instead of the
> commanding and impatient tone

Where are you getting this nonsense from ?

> you might try indicating you are
> willing to pay Chris for the improvements according to how Chris
> thinks they should be implemented. If you're lucky, Chris may create
> time for your improvements sooner rather than later. He may even do
> it for free.
>
> You can of course also do the work yourself and send him a pull
> request on github, but I've noticed he usually won't merge any large
> new pull requests he hasn't solicited. I assume they conflict with
> his other feature work branches, or don't have the quality Chris is
> looking for.

I highly object to the tone of your response. Bringing up a matter on
this mailing list related to a Boost library is not a command for anyone
to do anything. By responding the way you have done you are discouraging
people with issues from using Boost mailing lists to start a discussion
about a particular library.

[Niall Douglas]

On 15 Jan 2015 at 12:42, Edward Diener wrote:

> I highly object to the tone of your response. Bringing up a matter on
> this mailing list related to a Boost library is not a command for anyone
> to do anything. By responding the way you have done you are discouraging
> people with issues from using Boost mailing lists to start a discussion
> about a particular library.

I apologise if I have offended anyone on the list, including you
Edward.

However, there is an etiquette when dealing with deficiencies in open
source libraries. You first raise the issue with the library's
maintainers before going onto public lists - and before I replied to
the OP, I checked the github ASIO issue tracker and the Boost issue
tracker and found no mention of the deficiencies. It may be the case
that the OP has spoken to Chris by private email, but his post did
not indicate that. Furthermore, Chris fairly bluntly stated in the
ASIO release notes which added WinRT support that that support would
be limited, and he went into some detail as to how and why. That
would strongly suggests that the maintainer is well aware of the
limitations, and has a strong idea of what should be done about them
(if anything). Moreover, if he has left out a particular support for
something, he may well have very good reasons for that, including the
cost benefit reason.

So, go raise it with the maintainer first, and that's probably best
done as I mentioned via the ASIO github issue tracker which Chris
definitely responds quickly to. If the maintainer refuses to support
what you need, *then* come onto this list to see if anyone else is
having the same problem, *then* see if you can put together a
coalition of the willing. However, to be honest, I think the
maintainer will be happy to improve WinRT support, you just need to
prearrange what form he'd prefer it to come in.

And BTW, after you've talked to Chris and gotten green lit by him,
absolutely do ping this list with what you've agreed to do and ask
for feedback on it. The people I'm currently contracting for would be
very interested in improved WinRT support in ASIO. I'm sure so would
others on the asio-users ML. And as ASIO is going to be the
Networking TS, I daresay so would Microsoft, indeed you might even
get some improvements to WinRT to help ASIO along - we have the main
Microsoft engineer who ported Boost to WinRT on this mailing list.

[Edward Diener]

On 1/15/2015 4:25 PM, Niall Douglas wrote:
> On 15 Jan 2015 at 12:42, Edward Diener wrote:
>
>> I highly object to the tone of your response. Bringing up a matter on
>> this mailing list related to a Boost library is not a command for anyone
>> to do anything. By responding the way you have done you are discouraging
>> people with issues from using Boost mailing lists to start a discussion
>> about a particular library.
>
> I apologise if I have offended anyone on the list, including you
> Edward.
>
> However, there is an etiquette when dealing with deficiencies in open
> source libraries. You first raise the issue with the library's
> maintainers before going onto public lists - and before I replied to
> the OP, I checked the github ASIO issue tracker and the Boost issue
> tracker and found no mention of the deficiencies.

I do not know of anything within Boost which says that library
maintainers are supposed to be contacted directly before one posts
issues on the mailing lists. In fact I have always assumed that the
mailing lists were the correct way to first bring up an issue and only
if there was no response from anybody connected with the library in
question does one then attempt to go further. Regardless of how this
normally occurs please realize that the mailing lists are completely
viable ways of alerting library maintainers to issues regarding their
library, with the protocol normally being that the OP should have the
form of "[library] Some Subject" as the subject of the mailing list post.

I hope you also realize that programmers who use Boost, and who are not
contributors themselves to Boost libraries, do occasionally send mailing
lists messages to the developers mailing list and do not know anything
about supposed etiquettes about suggested changes to a library. They are
simple bringing up issues and assume the mailing lists are one way to do
this, which they in fact are.

Of course programmmers can file bug and/or suggestion reports on Boost
trac or issue pull requests for changes on Github. But I would actually
expect attempting to directly contact a library developer is a thing a
programmer would do only as a last resort, if other things met little or
no response.

Like you I also viewed the OP as a very large request and or suggestion.
But a library maintainer has every right to respond as he sees fit, one
of those responses being that whatever changes which are being asked for
he is unwilling to implement for his own given reasons. But certainly
nobody should come down on anyone bringing up an issue regarding a
library on this mailing list unless the post is insulting or derogatory
to that library for personal reasons. That certainly was not the case in
any respect in the OP.

[Rob Stewart]

On January 15, 2015 5:37:15 PM EST, Edward Diener <eldi...@tropicsoft.com> wrote:
> On 1/15/2015 4:25 PM, Niall Douglas wrote:
> > On 15 Jan 2015 at 12:42, Edward Diener wrote:
> >
> >> I highly object to the tone of your response. Bringing up a matter
> on
> >> this mailing list related to a Boost library is not a command for
> anyone
> >> to do anything. By responding the way you have done you are
> discouraging
> >> people with issues from using Boost mailing lists to start a
> discussion
> >> about a particular library.
> >
> > I apologise if I have offended anyone on the list, including you
> > Edward.

Thanks for apologizing.

> > However, there is an etiquette when dealing with deficiencies in
> open
> > source libraries. You first raise the issue with the library's
> > maintainers before going onto public lists - and before I replied to
> > the OP, I checked the github ASIO issue tracker and the Boost issue
> > tracker and found no mention of the deficiencies.
>
> I do not know of anything within Boost which says that library
> maintainers are supposed to be contacted directly before one posts
> issues on the mailing lists. In fact I have always assumed that the
> mailing lists were the correct way to first bring up an issue and only
> if there was no response from anybody connected with the library in
> question does one then attempt to go further.

Indeed, Boost does not work that way. One may communicate with a library maintainer any way one wishes and that includes using this list.

___
Rob

(Sent from my portable computation engine)