Too many EOF's using boost::asio
I have a TCP server and client with following read and write functions: ----------------- Writes ---------------------- void SomeClass::startWrite() { //m_writeBuffer is boost::asio::streambuf..m_writeQueue is std::dequestd::string m_writeBuffer.sputn(&m_writeQueue.at(0)[0], m_writeQueue.at(0).size()); //m_objStrandWrite is boost::asio::strand boost::asio::async_write( getSocket(), m_writeBuffer, m_objStrandWrite.wrap([this](const boost::system::error_code &e, std::size_t bytesTxd){writeHandler(e, bytesTxd);}) ); } void SomeClass::writeHandler(const boost::system::error_code &refErrorCode, std::size_t bytesTxd) { if(!m_bIsStopped) { m_writeQueue.pop_front(); if(refErrorCode) { if(refErrorCode != boost::asio::error::operation_aborted) { std::cerr << "Write Error: " << refErrorCode.message() << std::endl; stop(); } } else { if(!m_writeQueue.empty()) { startWrite(); } } } } ------------------- Reads ----------------- void SomeClass::startRead() { //m_readBuffer is boost::asio::streambuf..m_objStrandRead is boost::asio::strand boost::asio::async_read_until( getSocket(), m_readBuffer, m_szTermString, m_objStrandRead.wrap([this](const boost::system::error_code &e, std::size_t bytesRxd){readHandler(e, bytesRxd);}) ); } void SomeClass::readHandler(const boost::system::error_code &refErrorCode, std::size_t bytesRxd) { if(!m_bIsStopped) { if(refErrorCode) { if(refErrorCode != boost::asio::error::operation_aborted) { std::cerr << "Read error: " << refErrorCode.message() << std::endl; stop(); } } else { if(bytesRxd) { std::string szRxdData; szRxdData.resize(bytesRxd); m_readBuffer.sgetn(&szRxdData[0], bytesRxd); } startRead(); } } } I get very frequent End Of File (EOF) error on client's read. It is not always but frequent. I am running a threadpool by asking multiple std::threads to execute io_service::run() which never quits until io_service::stop() is called. The data given by the server is almost never more than 5MB. As you see in the code, for any error I call stop() which shuts down the connection gracefully. <Q> *Is there something wrong I'm doing because I see no reason for EOF error. Why should the server close/shutdown the connection?* The code does not do that explicitly. Anyway it is random - out of 10 times maybe 5 are successful reads and 5 become EOF's and I have to restart my client executable to connect again in each of those cases. Other sockets don't do that - eg., I've tested with QTcpSocket of Qt framework and it works all the time (no randomness). -- View this message in context: http://boost.2283326.n4.nabble.com/Too-many-EOF-s-using-boost-asio-tp4651173... Sent from the Boost - Users mailing list archive at Nabble.com.
Gesendet: Freitag, 30. August 2013 um 23:09 Uhr Von: ustulation
An: boost-users@lists.boost.org Betreff: [Boost-users] Too many EOF's using boost::asio //m_writeBuffer is boost::asio::streambuf..m_writeQueue is std::dequestd::string m_writeBuffer.sputn(&m_writeQueue.at(0)[0], m_writeQueue.at(0).size());
Hm. How big is your data? deque is not like vector giving you an array of elements. std::deque splits internally into differen chunks, maybe your problems come from this. I can't really see that using deque in this way would be safe. If your data is always smaller then the chunksize of deque, things are ok, other wise, well you're surely not getting what you expect. kind regards, Jens Weller
On Fri, Aug 30, 2013 at 11:25:39PM +0200, Jens Weller wrote:
Gesendet: Freitag, 30. August 2013 um 23:09 Uhr Von: ustulation
An: boost-users@lists.boost.org Betreff: [Boost-users] Too many EOF's using boost::asio //m_writeBuffer is boost::asio::streambuf..m_writeQueue is std::dequestd::string m_writeBuffer.sputn(&m_writeQueue.at(0)[0], m_writeQueue.at(0).size());
Hm. How big is your data? deque is not like vector giving you an array of elements. std::deque splits internally into differen chunks, maybe your problems come from this. I can't really see that using deque in this way would be safe. If your data is always smaller then the chunksize of deque, things are ok, other wise, well you're surely not getting what you expect.
His code is accessing the underlying storage of a std::string, that happens to be in a deque, which is fine as long as you're not invalidating the elements of the deque. Anyway, this might be a manifestation of the 1.54.0 bug with Boost.ASIO+IOCP having spurious EOFs on Windows: https://svn.boost.org/trac/boost/ticket/8967 -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote
On Fri, Aug 30, 2013 at 11:25:39PM +0200, Jens Weller wrote:
Gesendet: Freitag, 30. August 2013 um 23:09 Uhr Von: ustulation <
ustulation@
>
An:
boost-users@.boost
Betreff: [Boost-users] Too many EOF's using boost::asio
//m_writeBuffer is boost::asio::streambuf..m_writeQueue is std::deque std::string m_writeBuffer.sputn(&m_writeQueue.at(0)[0], m_writeQueue.at(0).size());
Hm. How big is your data? deque is not like vector giving you an array of elements. std::deque splits internally into differen chunks, maybe your problems come from this. I can't really see that using deque in this way would be safe. If your data is always smaller then the chunksize of deque, things are ok, other wise, well you're surely not getting what you expect.
His code is accessing the underlying storage of a std::string, that happens to be in a deque, which is fine as long as you're not invalidating the elements of the deque. -- Lars Viklund |
zao@.umu
_______________________________________________ Boost-users mailing list
Boost-users@.boost
Yes, the only assumption i make here is that std::string would store data contiguously and as I use c++11 I think this is the case (the speed of sputn and sgetn is too tempting to let go) Lars Viklund wrote
Anyway, this might be a manifestation of the 1.54.0 bug with Boost.ASIO+IOCP having spurious EOFs on Windows: https://svn.boost.org/trac/boost/ticket/8967
-- Lars Viklund
Oh, I see! We had started the project using boost 1.53 and had done testing then. I suspect we had seen no such problems hence was not caught then. On silently upgrading to boost 1.54 the only thing we cared was compilation which was successful at once. The documentations hadn't changed and we didn't care much, but I guess the problem lurked all the time since then. Only now on redoing some alpha test cases we realized. So what would you suggest? And though i didn't mention - you are right, it /is/ on Windows. Do I use the patch in the link you mentioned (because there seems to be some disagreement on its philosophy) or has christopher kohlhoff (I infer he's the asio developer) done something about it? Thanks -- View this message in context: http://boost.2283326.n4.nabble.com/Too-many-EOF-s-using-boost-asio-tp4651173... Sent from the Boost - Users mailing list archive at Nabble.com.
On Sat, Aug 31, 2013 at 01:23:35AM -0700, ustulation wrote:
Lars Viklund wrote
Anyway, this might be a manifestation of the 1.54.0 bug with Boost.ASIO+IOCP having spurious EOFs on Windows: https://svn.boost.org/trac/boost/ticket/8967
Oh, I see! We had started the project using boost 1.53 and had done testing then. I suspect we had seen no such problems hence was not caught then. On silently upgrading to boost 1.54 the only thing we cared was compilation which was successful at once. The documentations hadn't changed and we didn't care much, but I guess the problem lurked all the time since then. Only now on redoing some alpha test cases we realized.
So what would you suggest? And though i didn't mention - you are right, it /is/ on Windows. Do I use the patch in the link you mentioned (because there seems to be some disagreement on its philosophy) or has christopher kohlhoff (I infer he's the asio developer) done something about it?
There's three workarounds you can try out in the short term: 1) try the patch 2) use Asio with the BOOST_ASIO_DISABLE_IOCP flag 3) revert Boost whole-sale to 1.53 This problem has cropped up in the #boost channel as a hidden problem taking us many days to find, auditing pretty much every single piece of the user code, before eventually stumbling over the bug report. In any way, it's a problem that needs to be solved. If Asio does things incorrectly, it doesn't matter how fast it manages to does it. If I read the two bug reports right, the pre-1.54 way was stable-and-boring-but-works, and the attempted improvements seem to have gone wrong. In my eyes, it's either for the Asio people to revert to the known-good way of 1.53, or fix up their new implementation to work in reality. -- Lars Viklund | zao@acc.umu.se
Sorry for getting to this so late... -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Lars Viklund Sent: Saturday, August 31, 2013 8:01 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Too many EOF's using boost::asio
This problem has cropped up in the #boost channel as a hidden problem taking us many days to find, auditing pretty much every single piece of the user code, >before eventually stumbling over the bug report.
In any way, it's a problem that needs to be solved. If Asio does things incorrectly, it doesn't matter how fast it manages to does it.
If I read the two bug reports right, the pre-1.54 way was stable-and-boring-but-works, and the attempted improvements seem to have gone wrong. In my eyes, it's >either for the Asio people to revert to the known-good way of 1.53, or fix up their new implementation to work in reality.
There's also a very simple patch to try attached to https://svn.boost.org/trac/boost/ticket/8933 . We've since found that 8967 has the same root cause. Best regards, M. Scott Mueller
participants (4)
-
Jens Weller
-
Lars Viklund
-
Scott Mueller
-
ustulation