ASIO does not fully support Windows Runtime (WinRT), and a suggestion for providing support
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
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/
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.
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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
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.
On January 15, 2015 5:37:15 PM EST, 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.
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)
participants (4)
-
Edward Diener -
Moshe Rubin -
Niall Douglas -
Rob Stewart