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 _______________________________________________ Mailing list: https://launchpad.net/~linuxdcpp-team Post to : linuxdcpp-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~linuxdcpp-team More help : https://help.launchpad.net/ListHelp
