linuxdcpp-team team mailing list archive

[Andy Chmilenko <834278@xxxxxxxxxxxxxxxxxx>]

Tested this out a bit more, so I could get my story straight.

Running the hub on my Windows 7 Ultimate 64-bit, I could not get this
error when connecting from the host, and from my server over LAN or the
internet. When running over the internet, response was a bit slow but it
never dropped the connection.

Running the hub on my 2003 Server, I couldn't get this error when connecting from the host, but I got this error when connecting from over LAN and over the internet. Ever time I send the command in question it would give me this error.
Socket error is logged as: "The I/O operation has been aborted because of either a thread exit or an application request"

I tested this on r570

These are the bandwidth stats for one session. 1 user connected form
host (never got disconnected), and testing user over internet. 4 command
calls, 4 disconnects. Other sessions I did about 20.

Bandwidth stats: 
0 B	Bytes queued (0 B/user)
56.45 KiB	Total bytes queued (862 B/s)
588	Queue calls (98 B/call)
38.53 KiB	Total bytes sent (588 B/s)
209	Send calls (188 B/call)
2.90 KiB	Total bytes received (44 B/s)
62	Receive calls (47 B/call)

-- 
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 on repeated sending CMDs
  (threaded)

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