linuxdcpp-team team mailing list archive

[Andy Chmilenko <834278@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

I've been working on a python interface and it created it such that hub
commands are run in separate threads after the onMSG. When one specific
setting when changed it removes and modifies UCMDs and resends them to
all entities that support it. I am not completely sure why, when run
with the thread it seems like if a lot of commands are sent within
ManagedSocket the write to the socket is aborted sometimes. I don't run
into this problem when the command is run within onMSG before and value
is returned, and sometimes it doesn't have a problem and runs normally
even when it is threaded.

I thought has to be something to do with a buffer overflow, but it never
seems to enter that part of the condition.

Upon investigation it seems like inside the ManagedSocket::completeWrite receives an error and fails, which ends up disconnecting whatever client it was.
However, this error is boost::asio::error::operation_aborted and it doesn't seem like a fatal error. I added a condition for it to continue normally in this case it seems like everything still works fine, no more errors, everything sent properly.

if(!ec || ec == boost::asio::error::operation_aborted)

Does this seem like a reasonable solution? Or maybe it could point you
in the right direction

-----------
Attached my interface (wip), copy over adch++ stuff, run adchpp.py, register, edit users.txt to make yourself op. Do something like: !cfg cmd_chr +
and vice-versa: +cfg cmd_chr !

The cmd_chr change function resends UCMDs. I run into the problem
described when I change this setting.

** Affects: adchpp
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/834278

Title:
  ManagedSocket 'fails' and drops connection when sending large data

Status in ADCH++:
  New

Bug description:
  I've been working on a python interface and it created it such that
  hub commands are run in separate threads after the onMSG. When one
  specific setting when changed it removes and modifies UCMDs and
  resends them to all entities that support it. I am not completely sure
  why, when run with the thread it seems like if a lot of commands are
  sent within ManagedSocket the write to the socket is aborted
  sometimes. I don't run into this problem when the command is run
  within onMSG before and value is returned, and sometimes it doesn't
  have a problem and runs normally even when it is threaded.

  I thought has to be something to do with a buffer overflow, but it
  never seems to enter that part of the condition.

  Upon investigation it seems like inside the ManagedSocket::completeWrite receives an error and fails, which ends up disconnecting whatever client it was.
  However, this error is boost::asio::error::operation_aborted and it doesn't seem like a fatal error. I added a condition for it to continue normally in this case it seems like everything still works fine, no more errors, everything sent properly.

  if(!ec || ec == boost::asio::error::operation_aborted)

  Does this seem like a reasonable solution? Or maybe it could point you
  in the right direction

  -----------
  Attached my interface (wip), copy over adch++ stuff, run adchpp.py, register, edit users.txt to make yourself op. Do something like: !cfg cmd_chr +
  and vice-versa: +cfg cmd_chr !

  The cmd_chr change function resends UCMDs. I run into the problem
  described when I change this setting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/834278/+subscriptions