asio-users Mailing List for asio C++ library (Page 3)
Brought to you by:
chris_kohlhoff
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(6) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(7) |
Nov
(8) |
Dec
(11) |
2006 |
Jan
(11) |
Feb
(14) |
Mar
(8) |
Apr
(3) |
May
(27) |
Jun
(15) |
Jul
(43) |
Aug
(64) |
Sep
(19) |
Oct
(44) |
Nov
(69) |
Dec
(82) |
2007 |
Jan
(79) |
Feb
(153) |
Mar
(169) |
Apr
(148) |
May
(181) |
Jun
(114) |
Jul
(152) |
Aug
(104) |
Sep
(77) |
Oct
(128) |
Nov
(185) |
Dec
(215) |
2008 |
Jan
(100) |
Feb
(116) |
Mar
(115) |
Apr
(74) |
May
(152) |
Jun
(107) |
Jul
(117) |
Aug
(115) |
Sep
(141) |
Oct
(75) |
Nov
(31) |
Dec
(47) |
2009 |
Jan
(51) |
Feb
(65) |
Mar
(54) |
Apr
(60) |
May
(6) |
Jun
(107) |
Jul
(82) |
Aug
(133) |
Sep
(144) |
Oct
(11) |
Nov
(54) |
Dec
(26) |
2010 |
Jan
(30) |
Feb
(17) |
Mar
(93) |
Apr
(47) |
May
(93) |
Jun
(73) |
Jul
(32) |
Aug
(60) |
Sep
(59) |
Oct
(58) |
Nov
(71) |
Dec
(28) |
2011 |
Jan
(58) |
Feb
(65) |
Mar
(38) |
Apr
(83) |
May
(45) |
Jun
(70) |
Jul
(71) |
Aug
(7) |
Sep
(33) |
Oct
(65) |
Nov
(33) |
Dec
(16) |
2012 |
Jan
(13) |
Feb
(32) |
Mar
(30) |
Apr
(67) |
May
(57) |
Jun
(59) |
Jul
(8) |
Aug
(61) |
Sep
(48) |
Oct
(23) |
Nov
(29) |
Dec
(8) |
2013 |
Jan
(37) |
Feb
(20) |
Mar
(11) |
Apr
(11) |
May
(9) |
Jun
(26) |
Jul
(6) |
Aug
(18) |
Sep
(7) |
Oct
(29) |
Nov
(2) |
Dec
(17) |
2014 |
Jan
(11) |
Feb
(12) |
Mar
(6) |
Apr
(26) |
May
(17) |
Jun
(12) |
Jul
(12) |
Aug
|
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(7) |
2015 |
Jan
(3) |
Feb
(3) |
Mar
(7) |
Apr
(23) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(33) |
Sep
(16) |
Oct
(2) |
Nov
(2) |
Dec
(13) |
2016 |
Jan
(7) |
Feb
(22) |
Mar
(11) |
Apr
|
May
(10) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
(29) |
Nov
(3) |
Dec
(21) |
2017 |
Jan
(4) |
Feb
(31) |
Mar
(8) |
Apr
(4) |
May
(1) |
Jun
(4) |
Jul
(32) |
Aug
(28) |
Sep
(2) |
Oct
(11) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
|
Nov
(4) |
Dec
(20) |
2019 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(11) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2023 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
(3) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2024 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: D. C. D. <Cam...@bl...> - 2020-07-27 13:10:07
|
Hello, I have an asio socket server on Windows with which I would like to use a thread local storage object. It appears that internally asio is using 16 worker threads to process completion handlers. Is there a way to allocate the TLS object for each internal asio thread? Forgive me if my terminology is wrong, I am pretty new to asio. Thanks! Regards, Cameron D. Cameron DeHeer Vice President, Research & Development Blaze Systems Corporation Phone: 302.733.7236 Fax: 302.733.7248 Email: Cam...@bl...<mailto:Cam...@bl...> Web: www.blazesystems.com Follow: [cid:ima...@01...5021D0] <http://www.facebook.com/blazesystems> [cid:ima...@01...5021D0] <http://www.linkedin.com/company/blaze-systems-corporation> [cid:ima...@01...5021D0] <http://www.twitter.com/blaze_systems> |
From: NAD <ro...@on...> - 2020-07-22 05:19:31
|
please remove my mail from this mailing list thanks Nadav From: Vinnie Falco <vin...@gm...> To: <asi...@li...> Sent: 7/21/2020 11:45 PM Subject: Re: [asio-users] Native Windows ssl::stream support On Tue, Jul 21, 2020 at 9:39 AM Kasper Laudrup <la...@st...> wrote: > I was planning to look into the SChannel approach as > that seems closest to how the OpenSSL implementation works. Buffer-oriented ("bring your own socket") would be the most straightforward, and also the area in which my colleagues and I have the most experience. We can collaborate in the free C++ Language Slack Workspace (get the invite at https://cppalliance.org/slack). And we can help with setting up a GitHub repository for CI and testing workflow - the benefit of setting up a public repository early is that stakeholders can look at code and comment on it, submit reviews, even contribute by writing tests or example programs. Let me know if and when you are ready for this (sooner is better). Thanks _______________________________________________ asio-users mailing list asi...@li... https://lists.sourceforge.net/lists/listinfo/asio-users _______________________________________________ Using Asio? List your project at http://think-async.com/Asio/WhoIsUsingAsio |
From: Vinnie F. <vin...@gm...> - 2020-07-21 20:45:38
|
On Tue, Jul 21, 2020 at 9:39 AM Kasper Laudrup <la...@st...> wrote: > I was planning to look into the SChannel approach as > that seems closest to how the OpenSSL implementation works. Buffer-oriented ("bring your own socket") would be the most straightforward, and also the area in which my colleagues and I have the most experience. We can collaborate in the free C++ Language Slack Workspace (get the invite at https://cppalliance.org/slack). And we can help with setting up a GitHub repository for CI and testing workflow - the benefit of setting up a public repository early is that stakeholders can look at code and comment on it, submit reviews, even contribute by writing tests or example programs. Let me know if and when you are ready for this (sooner is better). Thanks |
From: Scott M. <smu...@os...> - 2020-07-21 20:16:45
|
Hello, The Windows Secure Socket extensions are a way to negotiate using the IPsec services for network connections. It does not use TLS, but it looks like it would be trivial to plug this IPsec negotiation straight into ASIO by invoking the secure socket extension calls on your sockets before handing them off to ASIO, and then checking to see what kind of properties the IPsec channels have after the connections succeed. The Schannel methods are transport agnostic, so it should be possible to use these in ASIO just like OpenSSL. The only real gotchas in Schannel involve making certain that the use patterns are correct- the buffer set-up, renegotiation and shutdown are all handled properly. There is documentation for these, but it is tricky to navigate and the samples are strange (everything is under the same SSPI umbrella). Microsoft documentation in this arena is very sparse and only really makes sense if you are referring to a working sample. If you can find the Windows 2000 SDK, you'll find some complete (more or less) samples that implement an Schannel client and server. I've worked with this quite a bit in the past, so I could probably help with this some, time permitting. Best regards, M. Scott Mueller Staff engineer- ACME team (communications and fundamental types) OSIsoft, LLC -----Original Message----- From: Kasper Laudrup <la...@st...> Sent: Tuesday, July 21, 2020 9:38 AM To: asi...@li... Subject: [EXTERNAL] Re: [asio-users] Native Windows ssl::stream support Caution: This email came from outside the company. ______________________________________________________________________ On 21/07/2020 18.08, Vinnie Falco wrote: > > Well, I still think it is worth discussing with other folks, as this > can only help to inform your efforts. > Of course. I appreciate the help I can get. > How does Windows TLS work? Is it buffer-oriented? Or does Windows > control the socket? The answer to this question will have dramatic > influence on how your code is designed. If Windows wants to control > the socket, it will require more finesse and understanding of Asio to > author an I/O object that implements Windows TLS. > As far as I can tell, both options are supported. You can either make Windows control the socket: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_winsock_using-2Dsecure-2Dsocket-2Dextensions&d=DwICAg&c=rxxrGm2iek7pTJSSe1mAiw&r=5upJxiFcubzQpxbhINWH-YRVUQOICqCqDS6nudbYCog&m=ysNPt32sac-Xm_jZPu-PyhFvXoZ0CNU7n2LOhku2kPQ&s=LQ8QPC7nI9lEtUXK5MpJTBlZrBNAqlHe8VawMuEtHYs&e= Or use SChannel as a wrapper around an existing socket: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_windows_win32_secauthn_using-2Dsspi-2Dwith-2Da-2Dwindows-2Dsockets-2Dclient&d=DwICAg&c=rxxrGm2iek7pTJSSe1mAiw&r=5upJxiFcubzQpxbhINWH-YRVUQOICqCqDS6nudbYCog&m=ysNPt32sac-Xm_jZPu-PyhFvXoZ0CNU7n2LOhku2kPQ&s=cXlJKNwADtsI5G0IL7LoIJJa5PsOA1sP0HB31yEQOYE&e= I was planning to look into the SChannel approach as that seems closest to how the OpenSSL implementation works. Kind regards, Kasper Laudrup _______________________________________________ asio-users mailing list asi...@li... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_asio-2Dusers&d=DwICAg&c=rxxrGm2iek7pTJSSe1mAiw&r=5upJxiFcubzQpxbhINWH-YRVUQOICqCqDS6nudbYCog&m=ysNPt32sac-Xm_jZPu-PyhFvXoZ0CNU7n2LOhku2kPQ&s=epSZDACk8AX1j9elzqbDb_YCj5u4428Rl1Mo1JNeOyI&e= _______________________________________________ Using Asio? List your project at https://urldefense.proofpoint.com/v2/url?u=http-3A__think-2Dasync.com_Asio_WhoIsUsingAsio&d=DwICAg&c=rxxrGm2iek7pTJSSe1mAiw&r=5upJxiFcubzQpxbhINWH-YRVUQOICqCqDS6nudbYCog&m=ysNPt32sac-Xm_jZPu-PyhFvXoZ0CNU7n2LOhku2kPQ&s=FeDTmx2mGsUn6CwJ4zETO9Z7B6s-ZkLyGCTwkvzldM8&e= |
From: Kasper L. <la...@st...> - 2020-07-21 16:38:35
|
On 21/07/2020 18.08, Vinnie Falco wrote: > > Well, I still think it is worth discussing with other folks, as this > can only help to inform your efforts. > Of course. I appreciate the help I can get. > How does Windows TLS work? Is it buffer-oriented? Or does Windows > control the socket? The answer to this question will have dramatic > influence on how your code is designed. If Windows wants to control > the socket, it will require more finesse and understanding of Asio to > author an I/O object that implements Windows TLS. > As far as I can tell, both options are supported. You can either make Windows control the socket: https://docs.microsoft.com/en-us/windows/win32/winsock/using-secure-socket-extensions Or use SChannel as a wrapper around an existing socket: https://docs.microsoft.com/en-us/windows/win32/secauthn/using-sspi-with-a-windows-sockets-client I was planning to look into the SChannel approach as that seems closest to how the OpenSSL implementation works. Kind regards, Kasper Laudrup |
From: Vinnie F. <vin...@gm...> - 2020-07-21 16:09:12
|
On Tue, Jul 21, 2020 at 5:45 AM Kasper Laudrup <la...@st...> wrote: > If I could get something like the example SSL client to work with native > SSL support on Windows, even if the solution was full of hacks and far > from a working solution, then I could take it from there and see if I > could make it a real boost library. Well, I still think it is worth discussing with other folks, as this can only help to inform your efforts. How does Windows TLS work? Is it buffer-oriented? Or does Windows control the socket? The answer to this question will have dramatic influence on how your code is designed. If Windows wants to control the socket, it will require more finesse and understanding of Asio to author an I/O object that implements Windows TLS. Thanks |
From: Kasper L. <la...@st...> - 2020-07-21 12:45:01
|
On 21/07/2020 13.27, Arvid Norberg wrote: > > There is GnuTLS support here: > > https://github.com/paullouisageneau/boost-asio-gnutls > > but it's not part of the official asio package, nor boost. > Thanks a lot. That might be worth looking at as a starting point for a similar implementation for Windows. Kind regards, Kasper Laudrup |
From: Kasper L. <la...@st...> - 2020-07-21 12:44:14
|
On 21/07/2020 01.45, Vinnie Falco wrote: > On Mon, Jul 20, 2020 at 2:46 PM Kasper Laudrup <la...@st...> wrote: >> Since boost and boost asio aims to be cross platform, I've been >> wondering why the SSL (or TLS) support in asio is so dependent on OpenSSL. > > I'm just going to venture a guess here, but the author of Asio only > has so much time. > That's a very reasonable and likely explanation, I was only wondering if there might be some other reason. >> I would very much like to have a go at implementing a wrapper for >> something other than openssl, even though it's probably way beyond my >> skills, > > Others and I would be very interested in seeing work of this type > completed. If you are reasonably proficient in Asio, I would be open > to providing assistance for getting something like this accomplished. > > I also think that such a project would be very viable as its own Boost library. > > If you are interested please email me privately and we'll get you started! > Thanks a lot. I guess my first attempt would be to make an extremely ugly proof-of-concept. If I could get something like the example SSL client to work with native SSL support on Windows, even if the solution was full of hacks and far from a working solution, then I could take it from there and see if I could make it a real boost library. If I get there I'll definitely consider your offer. Thanks once again. Kind regards, Kasper Laudrup |
From: Arvid N. <arv...@gm...> - 2020-07-21 11:27:19
|
On Mon, Jul 20, 2020 at 11:46 PM Kasper Laudrup <la...@st...> wrote: > Since boost and boost asio aims to be cross platform, I've been > wondering why the SSL (or TLS) support in asio is so dependent on OpenSSL. > > I'm mainly interested in native support for secure sockets on Windows > since that's one of the platforms I (unfortunately) have to support for > work, but I'm wondering why another implementation like GnuTLS isn't > supported either? > There is GnuTLS support here: https://github.com/paullouisageneau/boost-asio-gnutls but it's not part of the official asio package, nor boost. -- Arvid Norberg |
From: Vinnie F. <vin...@gm...> - 2020-07-20 23:47:15
|
On Mon, Jul 20, 2020 at 2:46 PM Kasper Laudrup <la...@st...> wrote: > Since boost and boost asio aims to be cross platform, I've been > wondering why the SSL (or TLS) support in asio is so dependent on OpenSSL. I'm just going to venture a guess here, but the author of Asio only has so much time. > I would very much like to have a go at implementing a wrapper for > something other than openssl, even though it's probably way beyond my > skills, Others and I would be very interested in seeing work of this type completed. If you are reasonably proficient in Asio, I would be open to providing assistance for getting something like this accomplished. I also think that such a project would be very viable as its own Boost library. If you are interested please email me privately and we'll get you started! Thanks |
From: Kasper L. <la...@st...> - 2020-07-20 21:46:03
|
Since boost and boost asio aims to be cross platform, I've been wondering why the SSL (or TLS) support in asio is so dependent on OpenSSL. I'm mainly interested in native support for secure sockets on Windows since that's one of the platforms I (unfortunately) have to support for work, but I'm wondering why another implementation like GnuTLS isn't supported either? It seems like some kind of abstraction has been made where the ssl::context could be implemented by something else, but I'm wondering why this hasn't been done already even if only as an experiment. I would very much like to have a go at implementing a wrapper for something other than openssl, even though it's probably way beyond my skills, but before I even try it would be nice to get some insight on this as I haven't been able to find this mentioned anywhere. Thanks a lot and kind regards, Kasper Laudrup |
From: John S. <js...@gm...> - 2020-05-10 21:40:03
|
Take the following code snippet: void Acceptor::StartNextAccept() { // _acceptor is of type: std::shared_ptr<boost::asio::ip::tcp::acceptor> _acceptor; _acceptor->async_accept([this](const boost::system::error_code& ec, net::ip::tcp::socket sock) { if (ec) { LogErrorCode(ec); // log on failure } else { _callback(sock); // pass socket on to the next component StartNextAccept(); // enqueue next accept } }); } In the fail case, the code just logs that an error happened and stops posting new async_accept calls. The socket effectively stops processing new connections. Are there classes of errors for async_accept, outside of the listen socket being {misconfigured, bad, closed, cancelled}, such that retrying the async_accept call would make sense? Or would that just be an infinite loop of errors? Or put another way, can accept calls fail transiently? If so, what error codes to pay attention to? Thanks, jrs |
From: Vinnie F. <vin...@gm...> - 2020-04-01 19:05:30
|
On Wed, Apr 1, 2020 at 11:54 AM Stanislav Zaikin <zs...@gm...> wrote: > Should I write my own basic io class? Just write it however you want, and make it work. The only thing you need to know, is that if you want to have some kind of global variables attached to the io_context (for example, to store the state for your event loop which processes all sockets) then you should create them using the "service" interface of io_context, and have each of your I/O objects query the io_context upon construction to obtain a reference to your global variables. These types and functions are relevant: https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/reference/execution_context__service.html https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/reference/io_context__service.html https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/reference/execution_context/add_service.html https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/reference/execution_context/has_service.html https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/reference/execution_context/use_service.html https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/reference/Service.html Beast WebSockets installs a service to clean up dangling suspended operations when the io_context is destroyed, you can have a look at how it uses these APIs: https://github.com/boostorg/beast/blob/048fe16fa3e8d4fc5d3e9fffc0586d7829a59c07/include/boost/beast/_experimental/test/impl/stream.ipp#L58 Regards |
From: Stanislav Z. <zs...@gm...> - 2020-04-01 18:53:10
|
Hello! I have a custom network stack (it processed packets in userspace) which exposed some functions in C library. It has its own listen, bind, accept functions and many other, and furthermore even custom epoll, select and poll. I want to expand asio in some away, just to support my application with this custom network stack. But I'm a bit confused how I can do it. Should I write my own basic io class? Or should I write custom socket service class (like reactive_socket_service_base)? And is it possible to use basic tcp classes (with any of them)? If there are any examples in open source please let me know. -- Best regards Stanislav Zaikin |
From: Szabolcs S. <cc...@ma...> - 2020-02-19 06:14:00
|
Hi, I'm trying to receive multicast traffic for multiple groups on the same interface. I'm using the multicast receiver example as a basis. I can subscribe to multiple groups, but when I receive a message in one of them, I need to know which group the packet was sent to originally. I thought about using the destination address of the packet, but that information seems unavailable in the async callback function. (The source address is there in sender_endpoint_, but I need the destination address.) Is there a way to extract this information for each packet? Thanks, -- Szabi |
From: Joseph S. <jso...@se...> - 2020-01-31 21:08:47
|
You can do it something like this: pstore_ = X509_STORE_new(); SSL_load_error_strings(); sslCertStoreLoad_WinStore("CA"); sslCertStoreLoad_WinStore("MY"); sslCertStoreLoad_WinStore("ROOT"); sslCertStoreLoad_WinStore("SPC"); sslCertStoreLoad_WinStore("TrustedPeople"); sslCertStoreLoad_WinStore("TrustedPublisher"); SSL_CTX_set_cert_store(ctx.native_handle(), pstore_); where sslCertStoreLoad_WinStore is something like void sslCertStoreLoad_WinStore(const char *winStoreName) { HCERTSTORE winStore = CertOpenStore( CERT_STORE_PROV_SYSTEM_A, X509_ASN_ENCODING | PKCS_7_ASN_ENCODING, 0, CERT_SYSTEM_STORE_LOCAL_MACHINE|CERT_STORE_READONLY_FLAG, (const void*)winStoreName); if(winStore == NULL) { return; } PCCERT_CONTEXT certCtx = NULL; while((certCtx = CertEnumCertificatesInStore(winStore, certCtx)) != NULL) { TCHAR szName[MAX_PATH] = { 0 }; X509 *cert = d2i_X509(NULL, (OPENSSL_d2i_TYPE)&certCtx->pbCertEncoded, certCtx->cbCertEncoded); X509_STORE_add_cert(pstore_, cert); X509_free(cert); } CertCloseStore(winStore, 0); } On 1/30/2020 4:29 PM, Jeffrey Chen wrote: > Hi, > asio supports SSL by providing certificate private/public keys or > certificate files path. However, in the Windows world, this is not the > common pattern. Windows has the certificate store. It takes care the > encryption/decryption for you. Is there a sample to interact asio with > the Windows certificate store? > > > > > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > _______________________________________________ > Using Asio? List your project at > http://think-async.com/Asio/WhoIsUsingAsio |
From: Jeffrey C. <cp...@ho...> - 2020-01-30 22:29:24
|
Hi, asio supports SSL by providing certificate private/public keys or certificate files path. However, in the Windows world, this is not the common pattern. Windows has the certificate store. It takes care the encryption/decryption for you. Is there a sample to interact asio with the Windows certificate store? |
From: Tristan M. <TMayfield@Braintrace.com> - 2019-11-21 21:52:39
|
Hi everyone, I'm new to the mailing list. Let me know if my questions belong elsewhere. I'm currently setting up a local daemon on Ubuntu 18.04, it listens on a local Unix socket for input in the form of a JSON object, does some calculations on that object and sends the new, modified JSON object back via the same socket. My goal is to essentially have it interact with another daemon on the box and between the two of them they have network monitoring capabilities. The issues I'm having are that this process works well if I manually use netcat to send one object at a time, but if I try to make a client that sends and receives at a much higher rate, the JSON gets mangled and can't be parsed correctly. I first thought this was because my daemon is multithreaded, but I changed the code to only have a reader and writer thread that access the socket. I thought the OS made sockets thread safe, but perhaps it doesn't? Should I just make an "input" and "output" local socket? My second thought involves incorrect buffer sizes, do I need the exact size of the buffer to be read from the socket when reading? Sorry if these are newbie questions. Most of my previous socket experience is in Java. I'd be happy to send some example code of how I'm doing all this, both client and server side. Thanks! |
From: Joseph S. <jso...@se...> - 2019-09-24 14:38:13
|
I need help with this. I don't seem to be able to figure it out. I've got customers where I am having to restart their server daily because of this so it's somewhat urgent. Using Visual Studio 2019 I am leaking coroutine stack frames at the following location in asio/impl/use_awaitable.hpp but my coroutines are all completing so I am not sure how that could be my fault. I have BOOST_ASIO_DISABLE_AWAITABLE_FRAME_RECYCLING defined as the awaitable frame recycling was obfuscating the leak. I see that an awaitable is constructed using the await transform function from that lambda. Is it possible this is leaking because this coroutine isn't completing (which is apparently by design)? template <typename Initiation, typename... InitArgs> static return_type initiate(Initiation initiation, use_awaitable_t<Executor>, InitArgs... args) { co_await [&](auto* frame) { handler_type handler(frame->detach_thread()); std::move(initiation)(std::move(handler), std::move(args)...); return static_cast<handler_type*>(nullptr); }; for (;;) {} // Never reached. #if defined(_MSC_VER) co_return dummy_return<typename return_type::value_type>(); #endif // defined(_MSC_VER) } |
From: Tom B. <tom...@bd...> - 2019-04-30 18:02:26
|
Using boost asio 1.69.0 on Windows. Planning to port to Linux. I'm trying to send a binary command to a serial device and get a binary reply. The device always receives the command and sends the reply. However, sometimes my async_read handler is called with 0 bytes transferred instead of with the reply. Inserting a small delay before the async_read works around the problem, although obviously that is not a reliable fix. Retrying the async_read is a better workaround. It looks like the problem is in boost::asio::detail::read_op<AsyncReadStream, MutableBufferSequence, MutableBufferIterator, CompletionCondition, ReadHandler> void operator()(const boost::system::error_code& ec, std::size_t bytes_transferred, int start = 0) { std::size_t max_size; switch (start_ = start) { case 1: max_size = this->check_for_completion(ec, buffers_.total_consumed()); do { stream_.async_read_some(buffers_.prepare(max_size), BOOST_ASIO_MOVE_CAST(read_op)(*this)); return; default: buffers_.consume(bytes_transferred); if ((!ec && bytes_transferred == 0) || buffers_.empty()) break; max_size = this->check_for_completion(ec, buffers_.total_consumed()); } while (max_size > 0); handler_(ec, buffers_.total_consumed()); } } If (!ec && bytes_transferred == 0) the asynchronous operation terminates before any data is received. This is contrary to the async_read documentation. In our workaround, retrying the async_read means we are basically polling for the reply. That is okay when we know a reply is coming within a few milliseconds. But we also need to handle an event from the device that it sends after a relatively long time. It would be good if we don't have to poll for that message. Is there an asio API we can use to get a characters available event callback from a serial port? If not, is there any chance that async_read can be changes so it will read the requested amount of data before completion? Thanks, Tom ******************************************************************* IMPORTANT MESSAGE FOR RECIPIENTS IN THE U.S.A.: This message may constitute an advertisement of a BD group's products or services or a solicitation of interest in them. If this is such a message and you would like to opt out of receiving future advertisements or solicitations from this BD group, please forward this e-mail to opt...@bd.... [BD.v1.0] ******************************************************************* This message (which includes any attachments) is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to the attorney-client privilege or other confidentiality protections. If you are not a designated recipient, you may not review, use, copy or distribute this message. If you received this in error, please notify the sender by reply e-mail and delete this message. Thank you. ******************************************************************* Corporate Headquarters Mailing Address: BD (Becton, Dickinson and Company) 1 Becton Drive Franklin Lakes, NJ 07417 U.S.A. |
From: Horton, T. <th...@ba...> - 2019-03-18 23:18:48
|
Hi All, I am working on a project where I use UDP sockets and serial ports to communicate with other devices. So I am planning on using Asio to take care of the details of these connections. However, I also need to communicate with other devices through I2C and SPI. It would be great if I could extend Asio to those connections as well. However, internet searches have turned up very little. One of the few discussions I've found on it is below. https://stackoverflow.com/questions/13937922/using-boost-asio-with-other-serial-devices-like-spi So my question is, is something like this possible with Asio? And has any work been done on this in the past? If someone could offer me some direction on how to approach this issue, it would be much appreciated! - Tyler This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address. |
From: Thomas I. <tho...@tu...> - 2019-01-24 19:10:17
|
Using two io_services sounds good. I did some more reading and put together an example based on some asio examples: template <class Handler> void async_read(const std::string& filename, Handler handler) { auto& strand = get_strand(filename); // Create executor_work for the handler's associated executor. auto work = asio::make_work_guard(handler); // Post a function object to do the work asynchronously. asio::post(strand, [this, filename, work, handler = std::move(handler)]() mutable { log("start heavy work on " + filename); std::this_thread::sleep_for(std::chrono::seconds(5)); log("finished heavy work on " + filename); std::string result = "after long consideration, here are the contents of " + filename; // Pass the result to the handler, via the associated executor. dispatch(work.get_executor(), [result = std::move(result), handler = std::move(handler)]() mutable { handler(std::move(result)); }); }); } asio::strand<asio::thread_pool::executor_type>& get_strand(const std::string& id) { std::lock_guard<std::mutex> guard(strand_lock_); auto it = strands_.try_emplace(id, pool_.get_executor()); return it.first->second; } std::mutex strand_lock_; std::map<std::string, asio::strand<asio::thread_pool::executor_type>> strands_; asio::thread_pool pool_; Calling it elsewhere like file_service_.async_read( filename, asio::bind_executor(strand_, [this, self](const std::string& result) { send(result); })); Full example https://gist.github.com/tilsche/74f4e5532fecf5e92542af96848c7b7d It appears to work and as far as I can tell code is running on the right threads. Nevertheless I am unsure whether I correctly understood all the aspects. Is it correct, that it is necessary to bind the handler to the calling execution context? I would appreciate any feedback on this. Thanks, Thomas On 1/18/19 7:04 PM, Matt Gruenke wrote: > First, you don't want to dispatch blocking operations, since dispatching one handler from another will directly execute (and therefore block) the former. > > Second, you can add a strand per file, but: > 1. That only increases concurrency if you've also got more threads. > 2. I thought your original use of strands was to keep a thread free to respond to incoming messages. > > You could increase the concurrency of your file operations, if you maintain fewer file strands than the total number of worker threads. Of course, you'll also want to ensure that all operations on a given file are funneled through the same strand. So, a better approach might be to have two io_services - one for messages and one for file I/O. Then, in the file I/O service, you can have as many strands as you like. > > > Matt > > > -----Original Message----- > From: Thomas Ilsche [mailto:tho...@tu...] > Sent: Friday, January 18, 2019 12:13 > To: asi...@li... > Subject: [asio-users] Emulating non-blocking file-IO with asio > > I am writing a service with asio that needs to do file-IO, including opening files, to answer certain messages. The protocol (AMQP /w TSL) is full-duplex and requires regular heartbeats. The files may be on network filesystems and it may be many. So there are cases where doing too much file-IO causes the service to miss heartbeats. > > Most unfortunately there seems to be no way to do non-blocking file-IO on Linux, especially opening files. So my idea is > > run an io_context with concurrency_hint == 2 do all general protocol (never blocking) stuff in one strand encapsulate all blocking file-IO and post it to one other strand. > > My hope is then that there can never be more than one file-io function blocking the io_context so that there is always a thread free to handle the rest. > > Is this a good idea? There doesn't seem to be much of a guarantee, particularly given that it is only a concurrency_*hint*. Does it make a difference whether i post/dispatch? > > Are there any, more idiomatic, alternatives? > > How could I exploit more parallelism for the file-IO when I could create an arbitrary number of strands - basically one per file? > > Thanks, > Thomas > > > _______________________________________________ > asio-users mailing list > asi...@li... > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fasio-users&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C213c25b5064246ac342508d67d685a0f%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C0%7C636834284493534876&sdata=ZEaGEnemlO2JP0j1wuIS2A3L2iGgUGr9hl%2BPjJ8as%2F4%3D&reserved=0 > _______________________________________________ > Using Asio? List your project at > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fthink-async.com%2FAsio%2FWhoIsUsingAsio&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C213c25b5064246ac342508d67d685a0f%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C0%7C636834284493534876&sdata=1ESJ5M9k2UQ%2F4CtwLOaZZllvJlPBbe12x4c8CF6BIqE%3D&reserved=0 > > > _______________________________________________ > asio-users mailing list > asi...@li... > https://lists.sourceforge.net/lists/listinfo/asio-users > _______________________________________________ > Using Asio? List your project at > http://think-async.com/Asio/WhoIsUsingAsio > |
From: Matt G. <mat...@jc...> - 2019-01-18 18:37:47
|
First, you don't want to dispatch blocking operations, since dispatching one handler from another will directly execute (and therefore block) the former. Second, you can add a strand per file, but: 1. That only increases concurrency if you've also got more threads. 2. I thought your original use of strands was to keep a thread free to respond to incoming messages. You could increase the concurrency of your file operations, if you maintain fewer file strands than the total number of worker threads. Of course, you'll also want to ensure that all operations on a given file are funneled through the same strand. So, a better approach might be to have two io_services - one for messages and one for file I/O. Then, in the file I/O service, you can have as many strands as you like. Matt -----Original Message----- From: Thomas Ilsche [mailto:tho...@tu...] Sent: Friday, January 18, 2019 12:13 To: asi...@li... Subject: [asio-users] Emulating non-blocking file-IO with asio I am writing a service with asio that needs to do file-IO, including opening files, to answer certain messages. The protocol (AMQP /w TSL) is full-duplex and requires regular heartbeats. The files may be on network filesystems and it may be many. So there are cases where doing too much file-IO causes the service to miss heartbeats. Most unfortunately there seems to be no way to do non-blocking file-IO on Linux, especially opening files. So my idea is run an io_context with concurrency_hint == 2 do all general protocol (never blocking) stuff in one strand encapsulate all blocking file-IO and post it to one other strand. My hope is then that there can never be more than one file-io function blocking the io_context so that there is always a thread free to handle the rest. Is this a good idea? There doesn't seem to be much of a guarantee, particularly given that it is only a concurrency_*hint*. Does it make a difference whether i post/dispatch? Are there any, more idiomatic, alternatives? How could I exploit more parallelism for the file-IO when I could create an arbitrary number of strands - basically one per file? Thanks, Thomas _______________________________________________ asio-users mailing list asi...@li... https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fasio-users&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C213c25b5064246ac342508d67d685a0f%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C0%7C636834284493534876&sdata=ZEaGEnemlO2JP0j1wuIS2A3L2iGgUGr9hl%2BPjJ8as%2F4%3D&reserved=0 _______________________________________________ Using Asio? List your project at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fthink-async.com%2FAsio%2FWhoIsUsingAsio&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C213c25b5064246ac342508d67d685a0f%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C0%7C636834284493534876&sdata=1ESJ5M9k2UQ%2F4CtwLOaZZllvJlPBbe12x4c8CF6BIqE%3D&reserved=0 |
From: Thomas I. <tho...@tu...> - 2019-01-18 17:13:26
|
I am writing a service with asio that needs to do file-IO, including opening files, to answer certain messages. The protocol (AMQP /w TSL) is full-duplex and requires regular heartbeats. The files may be on network filesystems and it may be many. So there are cases where doing too much file-IO causes the service to miss heartbeats. Most unfortunately there seems to be no way to do non-blocking file-IO on Linux, especially opening files. So my idea is run an io_context with concurrency_hint == 2 do all general protocol (never blocking) stuff in one strand encapsulate all blocking file-IO and post it to one other strand. My hope is then that there can never be more than one file-io function blocking the io_context so that there is always a thread free to handle the rest. Is this a good idea? There doesn't seem to be much of a guarantee, particularly given that it is only a concurrency_*hint*. Does it make a difference whether i post/dispatch? Are there any, more idiomatic, alternatives? How could I exploit more parallelism for the file-IO when I could create an arbitrary number of strands - basically one per file? Thanks, Thomas |
From: Matt G. <mat...@jc...> - 2018-12-29 16:36:16
|
The server can’t create the connection in its constructor, because you don’t yet know the port it’s on. That’s what accept produces – the port used by the connection. accept() listens on a “well-known port” and, each time a client connects, the actual connection is transacted on a new port. You’ll find that in any primer on TCP networking. The main question is whether your design supports only one concurrent connection, or multiple. If multiple, then you should think of having an accept() state machine and a separate state machine & instance for each connection, with each successfully-completed accept() spawning one. Either way, you don’t know what socket a new connection will use until accept() succeeds. Matt From: Jeff Abrahamson [mailto:je...@p2...] Sent: Saturday, December 29, 2018 03:03 To: asi...@li...; Matt Gruenke <mat...@jc...> Subject: Re: [asio-users] accept: asio vs BSD Hi, Matt. Thanks for the good suggestions. There's a bit of confusion, I think. First, about TcpConnection. I'm guessing you may have missed that the TcpServer constructor initialises a TcpConnection object. TcpServer::TcpServer(boost::asio::io_service& io_service, const int port, const TcpReceiveCallback& callback) : TcpConnection(io_service, port, callback), acceptor_(io_service_, boost::asio::ip::tcp::endpoint(tcp::v4(), port)), server_connection_state_(TcpServerNotConnected), server_reconnect_delay_(1) { The class TcpConnection just manages the things that are common between a client pattern (I connect to someone, say something, maybe listen for a response) and a server pattern (I listen for someone, then have a conversation with them). Naming is hard. Sorry for the confusion. I think the types are all easily inferred from the arguments passed in and the constructors I call. It's an imperfect art including enough code but not so much that it distracts. The port is an integer because ports are shorts. You lost me on that point. Indeed, I'd expect the compiler to have flagged that one if I'd found an interface that wanted a string or char*. But probably I'm confused: can you point me to the particular function you are looking at? The actual call to accept doesn't worry about ports so much as it looks at the queue of connection requests on a listening socket, picks the one at the head, and provides a new connected socket. From man (2) accept: The accept() system call is used with connection-based socket types (SOCK_STREAM, SOCK_SEQPACKET). It extracts the first connection request on the queue of pending connections for the listening socket, sockfd, creates a new connected socket, and returns a new file descriptor referring to that socket. The newly created socket is not in the listening state. The original socket sockfd is unaffected by this call. Jeff On 28/12/18 23:47, Matt Gruenke wrote: The other thing I don’t understand is why you’re accepting an integer port number, as a constructor parameter of TcpConnection. Now that I’m looking at the reference docs of async_accept(), I don’t see any version which initializes an integer port number. You must be going out of your way to get that? Or are you passing in the same port that the acceptor is listening on? The former is unnecessary, while the latter is incorrect. I would pass the socket you’re modifying with async_accept() to TcpConnection::TcpConnection(). Also, please post more complete code snippets, so we don’t have to play unnecessary guesswork. Matt From: Matt Gruenke Sent: Friday, December 28, 2018 17:29 To: 'je...@p2...<mailto:je...@p2...>' <je...@p2...><mailto:je...@p2...> Subject: RE: [asio-users] accept: asio vs BSD Some code appears to be missing. In the lambda in TcpServer::Accept(), you’re calling ReceiveHeader(), although that’s a member function of TcpConnection. It seems like there should be some code which constructs a new TcpConnection instance (probably also adding it to a pool) and calls ReceiveHeader() on it. Matt From: Jeff Abrahamson [mailto:je...@p2...] Sent: Friday, December 28, 2018 17:14 To: asi...@li...<mailto:asi...@li...> Subject: [asio-users] accept: asio vs BSD I'm chasing a strange bug (linux, ubuntu 16.04) in which a server sometimes complains that it is listening on an invalid socket. (Sometimes this code runs ok.) What I can see is that it listens, and before anyone can connect, it thinks it successfully accepted, tries to read, and hits an error: system:9 bad file descriptor. So I agree with the error, I just don't understand why the accept succeeds. [Note: you can skip the code, the real question is below.] Now what I'm doing seems straight-forward: I create an io_service object, construct a class that just holds the necessary objects for communication, that class calls async_accept(), and when that succeeds it calls async_read(). This is all happening on a highly quiescent vm, so I'm pretty sure nothing else is going on behind my back. I've pared the code down so that it really isn't doing anything other than this at this point. My real question is below the code, but I'm sharing the code pro forma and in the hopes that, as often happens, in preparing this question and cleaning extraneous cruft from the code I'll solve my problem myself and so delete the mail. boost::asio::io_service io_service; TcpServer tcp(io_service, port, [](const string& message) -> string { ... }); io_service.run(); TcpServer::TcpServer(boost::asio::io_service& io_service, const int port, const TcpReceiveCallback& callback) : TcpConnection(io_service, port, callback), acceptor_(io_service_, boost::asio::ip::tcp::endpoint(tcp::v4(), port)), server_connection_state_(TcpServerNotConnected), server_reconnect_delay_(1) { Accept(); } TcpConnection::TcpConnection(boost::asio::io_service& io_service, const int port, const TcpReceiveCallback& callback) : io_service_(io_service), port_(port), socket_(io_service_), dead_(false), error_count_(0), scheduler_(io_service), callback_(callback) {} void TcpServer::Accept() { LOGGABLE; LOG_INFO << "Accept requested."; server_connection_state_ = TcpServerAcceptWait; acceptor_.async_accept(socket_, [this](boost::system::error_code ec) { LOGGABLE; if (ec) { LOG_WARNING << "TcpServer failed to accept on socket: " << AsioError(ec) << " (delay=" << server_reconnect_delay_ << " seconds)"; if (server_reconnect_delay_ < 60) { // Exponential backoff, capped at 64 seconds. server_reconnect_delay_ *= 2; } scheduler_.AddTask("Accept", [this]() { return Accept(); }, server_reconnect_delay_, true); return; } server_connection_state_ = TcpServerConnected; LOG_INFO << "Accepting."; ReceiveHeader(); }); } void TcpConnection::ReceiveHeader() { LOGGABLE; if (dead_) { LOG_INFO << "TcpConnection::ReceiveHeader(): but we're dead."; return; } // receive_buffer_.clear(); boost::asio::async_read( socket_, boost::asio::buffer(receive_buffer_, kTcpHeaderSize), boost::asio::transfer_exactly(kTcpHeaderSize), [this](boost::system::error_code ec, std::size_t received_length) { LOGGABLE; if (ec) { LOG_WARNING << "Header read error: " << AsioError(ec); // ... } // ... ReceiveBody(read_length); }); } I'm sure this bug will fall in the morning. I know well enough that I've stared at this too long for one day. But my confusion is augmented by knowing that the accept(2) system call returns a new file descriptor: int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen); So my hypothesis this afternoon was briefly that asio's async_accept() must be doing the same thing and that I'm therefore calling read on the listening socket and not on the new connected socket. That doesn't quite make sense anyway, because I can see via netstat that no socket is connected (and I didn't run my utility to connect, and this is a quiescent vm constructed just for these tests). But this is bothering me now, because I've also spent a bunch of time reading in /usr/include/boost/asio/ and I don't find the call to the underlying system call accept(). My question is mostly on this last point: wtf, where is the connected fd represented in asio? -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 https://www.p27.eu/jeff/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p27.eu%2Fjeff%2F&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C457e53efe89441e8c3ec08d66d63fec1%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C0%7C636816673599990111&sdata=NT2Y7%2BVpQlyrWNqt%2FfF2Cjzq823jWpSLpb4hxyrK0ns%3D&reserved=0> https://www.transport-nantes.com/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transport-nantes.com%2F&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C457e53efe89441e8c3ec08d66d63fec1%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C0%7C636816673599990111&sdata=HOizMF6YF6WuGy%2FSFkeWebYkEXUm6L%2BJptC2eZTa4g4%3D&reserved=0> _______________________________________________ asio-users mailing list asi...@li...<mailto:asi...@li...> https://lists.sourceforge.net/lists/listinfo/asio-users<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fasio-users&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C457e53efe89441e8c3ec08d66d63fec1%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C1%7C636816673600000119&sdata=yZCVKhmFJdWuYUfRu4Y86Cs2mDJ5QTv57K0rKorXAGM%3D&reserved=0> _______________________________________________ Using Asio? List your project at http://think-async.com/Asio/WhoIsUsingAsio<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fthink-async.com%2FAsio%2FWhoIsUsingAsio&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C457e53efe89441e8c3ec08d66d63fec1%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C1%7C636816673600010131&sdata=SWgaYPXKa9mglhqcG0VwdJqz0%2Bm1bJt8qO9TLyZQvCE%3D&reserved=0> -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 https://www.p27.eu/jeff/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p27.eu%2Fjeff%2F&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C457e53efe89441e8c3ec08d66d63fec1%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C1%7C636816673600010131&sdata=iLnXbPY1ICax6dW0k1HGgckZGLFTRf4yx0lxosDjUjU%3D&reserved=0> https://www.transport-nantes.com/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.transport-nantes.com%2F&data=02%7C01%7Cmatthew.gruenke%40jci.com%7C457e53efe89441e8c3ec08d66d63fec1%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C1%7C636816673600020140&sdata=f%2FL8MQiWJ3Vv8e1wb1S0ItwitfODhV5bQfg8pj3pub4%3D&reserved=0> |