linuxdcpp-team team mailing list archive

[eMTee <2066921@xxxxxxxxxxxxxxxxxx>]

Questions and thoughts :

- SUD1_FEATURE("SUD1") suggests this is a revision of the feature. The
AirDC++ implementation mostly (but not fully, see below) follows the
extension standard. Any known reason for the numbering? If we implement
a proper support of standard we may just stick to "SUDP"?

- Util::strnicmp("adcs://", getHubUrl().c_str(), 7) == 0) in "Verify if
an ADCS hub and add Key" looks to be superfluous. Our isSecure()
function makes sure the hub is still online and connected through an SSL
socket. Btw. they have a similar function called isSocketSecure() in
AirDC++ and I'm not sure why they not use it there instead of this
rather ugly check...

- The protocol says SUDP should be signalled on ADCS hubs only. This
patch (and the original AirDC++ implementation) doesn't seem to obey
that.

- The protocol does not restrict but I think logic does dictate that
when SUDP support disabled and not signalled then we don't encrypt the
response, either, even if we receive a key. This can also lead to a
false sign of there's an enabled support of SUDP when in reality there
isn't.

- What's the reason of the switch from one time created scoped array of
bytevector buffer that lives until SearchManager runs to another way
where it is always allocated and goes out of scope when processing each
response?

- Why change 'x' to 'data' in SearchManager::onData and keep it
elsewhere. I think the name 'x' represents here the big unknown that has
just received...

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

Title:
  Add SUDP support

Status in DC++:
  New

Bug description:
  Proposed patch, adapted from AirDC++ by iceman50 included.

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