linuxdcpp-team team mailing list archive

[Pirre <pierreparys@xxxxxxxxxxx>]

Have used rev 320 on my redirect hub and problem still exist :(
Last version that somewhat managed to get the redirect msg over under very specific conditions was ver 279 (9 times out of 10)

1: it works only if the user just joins (i use a bot) it never seems to work when i do it manualy
2: there need to be atleast 47 users in the hub to make it work (lol) 

maybe above give some hints of what go's wrong ...

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

Status in ADCH++: Fix Committed

Bug description:
Somtimes when sending messages just before a disconnect the clients doesnt recieve all messages. After doing some testing i found out that slower handeling in ADCH++ made it harder to reproduce. My testing is based on the attached files.

Brief description of what's happening in ManagedSocket:
Note: sock is the asio sock thingie...

ManagedSocket::write is called 4 times with commands to send.
ManagedSocket disc is set to 5000+GET_TICK() when all 4 commands have arrived. (client.disconnect(0))
When the first command arrives, its added to the outBuff and ManagedSocket::prepareWrite is called().
Then the outBuff is passed over to sock->write() and writing is set to True.
While writing the remaining (3) commands gets added to the outBuff stack.
ManagedSocket::completeWrite is called for the 1st command (without error), this removes it from the outBuff stack, writing is set to False and calls prepareWrite() again.
prepareWrite() passes the remaining 3 commands in the outBuff to sock->write() .
ManagedSocket::completeWrite is called (without error), all data is reported as beeing sent.
writing is set to False, and prepareWrite() is called.
In prepareWrite, the fucn discovers that ( disc > 0) and outBuf.empty() then sock->close() is called.

It appears to me as the data has been sent, but still some times it doesn't get recieved in the client.

Providing config and scriptfiles for testing (thanks poy).
Tested on windows, not sure if this happens on linux.