Hopefully the protocol-related talk will be recovered from the old forum
as I also made calculations regarding the poor scalability of the Bloom
filters. The extension was tested in a few hubs several years ago and it
caused complaints from the users which in my opinion can't be solved
with the cur
The Bloom extension is disabled by default in AirDC++, as I believe it
causes more issues than it solves, as discussed on the DCBase forum.
Possibly the feature could be removed altogether.
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to D
As it seems like the feature won't be added in ADCH++, I've created my
own ADCH++ fork that supports the HBRI extension and handles validation
for the secondary IP protocol: https://github.com/maksis/adchpp-hbri
(HBRI support is also implemented in AirDC++)
--
You received this bug no
an be triggered by sending a malformed I4 param
(e.g. 999.999.999.999) to the hub.
Fixed in commit https://github.com/maksis/adchpp-
hbri/commit/d24e8972f9d1f2268fb8b1dec0dc3676f62fad17 of my HBRI fork.
To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/20
(e.g. 999.999.999.999) to the hub.
Fixed in commit https://github.com/maksis/adchpp-
hbri/commit/d24e8972f9d1f2268fb8b1dec0dc3676f62fad17 of my HBRI fork.
To manage notifications about this bug go to:
https://bugs.launchpad.net/adchpp/+bug/2081649/+subscrip
ing a malformed I4 param
(e.g. 999.999.999.999) to the hub.
Fixed in commit https://github.com/maksis/adchpp-
hbri/commit/d24e8972f9d1f2268fb8b1dec0dc3676f62fad17 of my HBRI fork.
** Affects: adchpp
Importance: Undecided
Status: New
--
You received this bug notification because you
Public bug reported:
https://datatracker.ietf.org/doc/html/rfc6886#section-3.4:
"When a mapping is destroyed successfully as a result of the client
explicitly requesting the deletion, the NAT gateway MUST send a
response packet that is formatted as defined in Section 3.3,
"Requesting a Mapping".
t/issues/450
https://github.com/airdcpp/airdcpp-windows/issues/63
While inspecting the issue more closely, I noticed that the client
receives about 300 search/CTM requests per second from the hub,
similar to these:
$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443
$Sear
arch/CTM requests per second from the hub,
similar to these:
$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443
$Search 82.146.38.183:443 F?F?0?1?p
$ConnectToMe maksis 82.146.38.183:80
$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443
cting the issue more closely, I noticed that the client
receives about 300 search/CTM requests per second from the hub,
similar to these:
$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443
$Search 82.146.38.183:443 F?F?0?1?p
$ConnectToMe maksis 82.146.38.183:80
$S
While inspecting the issue more closely, I noticed that the client
receives about 300 search/CTM requests per second from the hub, similar
to these:
$Search 82.146.38.183:80 F?F?0?1?t
$ConnectToMe maksis 82.146.38.183:443
$Search 82.146.38.183:443 F?F?0?1?p
$ConnectToMe maksis 82.146.38.183:80
$S
** Changed in: airdcpp
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1952754
Title:
[Hublist] tankafett[.]biz is no more a hublist
Status in AirDC++:
My original issue was about sending the TL -1 parameter and thus telling
the clients to never reconnect in case of overflow (even though the
error message shown to the user conflicts with that). If that is the way
how it's supposed to work, I'd rather set a different status for the
issue. Documenta
Bug #1088638 status changed in ADCH++:
Fix Committed => Won't Fix
https://bugs.launchpad.net/adchpp/+bug/1088638
"Not enough bandwidth available, please try again later"
This bug is linked to #690223.
Not enough bandwidth available, please try again later
https://answers.launchpad.net/adchpp
Looks like local file/directory names may also contain invalid
characters on non-Windows operating systems (at least on Linux). Those
may cause crashes and other issues, such as std::bad_alloc exceptions
when generating XML files.
https://github.com/airdcpp-web/airdcpp-webclient/issues/382
https:/
Looks like the benchmarks that you linked use 4-16 KB block sizes for
reading, which is far from optimal when doing regular sequential file
reads for larger files.
"Do you have any idea why in your Ubuntu 20.04 setup, 4MB buffers
performed notably worse than 1MB buffers?"
I'm not really sure, but
Public bug reported:
Steps to reproduce:
1. Start hashing a large file
2. Exit the application while the hashing is still in progress
3. Open HashIndex.xml and you'll find the file from there
Looks like the application isn't happy with the saved data as it begins
to hash the file again on next s
I ran some additional tests with different read buffer sizes on
different platforms. Cached hashing speed on macOS is CPU-bound and the
same most likely applies to Windows results as well (both disks are able
to read 1000 MB/s+). 1024 KB buffer size looks quite good based on the
tests.
macOS 11 (
FileReader::readDirect implementation with O_DIRECT/F_NOCACHE:
https://github.com/airdcpp/airdcpp-
windows/commit/eb1e075d5a69862c4f2255f9ea2f204bb70921ba
However, I don't think that the main point of the low-level
FileReader::readDirect implementation for Windows is skipping of the OS
buffers (co
AirDC++ actually has some kind of support for opening files O_DIRECT:
https://github.com/airdcpp/airdcpp-
windows/blob/b863d8626d95d0ee483572a5139f8f569b558c3f/airdcpp/airdcpp/File.cpp#L380-L394
(BUFFER_NONE isn't currently being used anywhere though when opening
files)
FileReader::readCached curr
Yeah this crash only happened for people using the Linux version of
AirDC++. FileReader::readMapped has always been disabled on Windows.
I'm not sure if mapped reading even makes sense in cases where the file
is only being read sequentially through once (maybe things were
different back in the day
Public bug reported:
FileReader::readMapped currently modifies the global SIGBUS handler in
order to catch read errors:
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/dcpp/FileReader.cpp#l289
Since the function can be called concurrently from different threads
(currently hashing/queue
Public bug reported:
Modern operating systems (Linux 2.4+, Windows Vista+) should support TCP
tuning (https://en.wikipedia.org/wiki/TCP_tuning) to enable higher per-
thread speeds with fast connections. However, the current default socket
buffer size (65536 bytes) set by the client will prevent th
I wonder how it was tested. Did you check the protocol communication or
confirm that the connection was actually rejected (instead of having an
unrelated connectivity issue, possibly because of the modifications)?
--
You received this bug notification because you are a member of
Dcplusplus-team,
I spent some time on the socks-related code and I was able to spot a few
issues:
Socket::socksUpdated (UDP, initialization)
- the function wasn't called on startup so the UDP functionality was
initialized only after updating settings
- waitConnected was missing after connect, causing the initiali
I believe that this specific problem has already been fixed
** Changed in: airdcpp
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/988891
Title:
socks does
I don't see how "TL-1" would protect from misbehavior in the IDENTIFY
state, as the error is not being sent in that state. I don't even
believe that the author of that code had a clear intention to send TL-1
in that case, and I'd rather consider it to be a bug (which would be
fixed by my patch). Th
"dropping protection against clients possibly misbehaving in the
IDENTIFY state and so endangering the hub stability"
What kind of misbehavior are you thinking?
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpa
Hmm, I don't follow. How does increasing OverflowTimeout help with this
issue? I can't spot any explanation from the code for that.
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to ADCH++.
https://bugs.launchpad.net/bugs/1088638
Title:
N
I'm getting a feeling that the context of this issue isn't being
understood. I'm aware of it happening only after the hub has been
restarted (and there are lots of users reconnecting).
As someone who used to run hubs with 10k+ users, I remember that the hub
is under heavy load after the restart. I
There's a separate (closed) report for AirDC++:
https://bugs.launchpad.net/airdcpp/+bug/1858229
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1860365
Title:
GeoIP database is not free any more
St
Related: https://github.com/airdcpp-web/airdcpp-webclient/issues/333
** Bug watch added: github.com/airdcpp-web/airdcpp-webclient/issues #333
https://github.com/airdcpp-web/airdcpp-webclient/issues/333
--
You received this bug notification because you are a member of
Dcplusplus-team, which is
** Also affects: airdcpp
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1818825
Title:
Use ALPN for protocol negotiation over TLS
Status in AirDC++:
N
"Of course your motive is to make it easy to move *to* Air and not away
from it (hence the import feature for the old DB format), but still..."
My motivation was to make it possible for people using older versions of
the application to upgrade without losing their data...
Regarding comment #14:
You make it sound like the file formats have been changed without proper
reasons. No, the hash database format wasn't changed because of this
issue (I just wanted to report my findings here while making the
rewrite). Dealing with a hash index XML file that could be several
gigabytes in size and bei
Ah right, the empty string check should have been added there as well
(even though empty data seems to be currently discarded at
https://sourceforge.net/p/dcplusplus/code/ci/f8540557bd5c28a9d0b3879b3e6b26f50ab670a6/tree/dcpp/SearchManager.cpp#l132).
The old NMDC code was moved as it was as I don't
Yeah, I took the code from AdcHub where it was public for some reason.
Here's a patch for DC++.
** Patch added: "udp.patch"
https://bugs.launchpad.net/dcplusplus/+bug/1722364/+attachment/4967758/+files/udp.patch
--
You received this bug notification because you are a member of
Dcplusplus-tea
AirDC++ now uses the regular dispatch function for parsing ADC UDP
commands that should fix the issue:
https://github.com/airdcpp/airgit/blob/6a40613788e7ed8a7478f4f1789bbd142a98d231/airdcpp/airdcpp/UDPServer.cpp#L130-L175
** Changed in: airdcpp
Status: New => Fix Released
--
You received
** Also affects: flylinkdc
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1722364
Title:
Invalid ADC commands sent via UDP will crash the app
Status in
*** This bug is a security vulnerability ***
Private security bug reported:
The AdcCommand parsing function will throw ParseException on invalid
commands:
https://sourceforge.net/p/dcplusplus/code/ci/default/tree/dcpp/AdcCommand.cpp#l37
However, SearchManager (UDPServer in AirDC++) won't catch t
Public bug reported:
This can be used by spam bots and other malicious clients to randomly
establish CCPM connections in hubs that have disabled the CCPM feature.
** Affects: airdcpp
Importance: Undecided
Status: New
** Affects: dcplusplus
Importance: Undecided
Status
Public bug reported:
The application still incorrectly shows that direct encrypted channel
has been established. AirDC++ also shouldn't allow establishing direct
encrypted channels when transfer encryption has been disabled.
** Affects: airdcpp
Importance: Undecided
Status: New
**
Non-Windows versions of Text::utf8ToWide and Text::wideToUtf8 won't
obviously handle UTF-16 surrogate pairs at all, thus producing incorrect
results. See the following test case for 🌍:
string toUtf8(const wstring& str) {
string tgt;
string::size_type n = str.length();
for (
** Also affects: airdcpp
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1665900
Title:
Case-sensitivity in filelists
Status in AirDC++:
New
Status in
Public bug reported:
Starting from version 3.30, AirDC++ refuses to load filelists that
contain directories with duplicate names in case-insensitive context
(since such lists are malformed according to ADC/NMDC specs). However,
this has caused some problems, since at least Eiskalt and Flylink will
** Changed in: airdcpp
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1656050
Title:
Compression errors with zlib 1.2.11
Status in AirDC++:
Fix Released
** Summary changed:
- Compression errors with zlib 1.2.10
+ Compression errors with zlib 1.2.11
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1656050
Title:
Compression errors with zlib 1.2.11
S
That's one way to do it.
For anyone using the code on Linux, it's very much impossible to notice
that such split is needed (before they actually run into problems and
try to figure out what's wrong). I'd strongly avoid such caveats that
rely on internal functionality changes of a library instead o
Should the check for "zs.avail_out == 0" still be kept in case zlib's
error policy is changed again in future and for compatibility with older
zlib versions? The code can't really be tied to a specific zlib version
on Linux.
--
You received this bug notification because you are a member of
Dcplus
No errors with a previously failing folder transfer after applying that
patch
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1656050
Title:
Compression errors with zlib 1.2.10
Status in AirDC++:
Yeah, it still happens with files as well. The next stable version
AirDC++ will be released with zlib 1.2.8 regardless of what happens with
this issue.
** Changed in: airdcpp
Status: New => Confirmed
--
You received this bug notification because you are a member of
Dcplusplus-team, which
I haven't experienced any errors with zlib 1.2.11 yet
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1656050
Title:
Compression errors with zlib 1.2.10
Status in AirDC++:
New
Status in ApexDC++:
*** This bug is a duplicate of bug 1656050 ***
https://bugs.launchpad.net/bugs/1656050
Public bug reported:
After updating zlib to version 1.2.10, transfers randomly fail because
of compression errors. Such errors happening on uploader's side won't
reported anywhere, the upload just gets disc
Public bug reported:
After updating zlib to version 1.2.10, transfers randomly fail because
of compression errors. Such errors happening on uploader's side won't
reported anywhere, the upload just gets disconnected.
Based on some debugging with AirDC++, the actual location where the
error happens
** Changed in: airdcpp
Status: New => Fix Released
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1649066
Title:
Invalid UTF-8 data is not always being rejected
Status in AirDC++:
Fix Rel
AirDC++ now implements the latter version.
This issue has also been partially discussed earlier:
https://sourceforge.net/p/dcplusplus/mailman/message/797137/
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net
An alternative patch that should sanitize the string instead
** Patch added: "utf8_replace.patch"
https://bugs.launchpad.net/dcplusplus/+bug/1649066/+attachment/4795240/+files/utf8_replace.patch
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subsc
Similar patch for DC++ with test included.
Seems that the non-Windows version of Text::utf8ToWide could be used to
sanitize invalid characters already. I'm not sure that why there is a
separate implementation for Windows as the other code doesn't call any
platform-specific functions (the same appl
AirDC++ will now just replace invalid data when loading config files:
https://github.com/airdcpp/airgit/commit/6ab6e22770d1c6d61a5c25a6d58fb6cdedc67858
Since I generally expect this to affect only (a small number of)
favorite hub names and descriptions (and recent hubs in AirDC++), I find
the solu
The validation function is cheap and there is effectively no difference
in filelist loading times.
Since it's possible to add favorite hubs directly from the hublist, it's
quite likely that there are users with malformed data in their
Favorites.xml as well. Disabling the validity check for certain
This patch for DC++ addresses 1) and 3)
** Patch added: "utf8.patch"
https://bugs.launchpad.net/dcplusplus/+bug/1649066/+attachment/4793524/+files/utf8.patch
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad
I've implemented UTF-8 validation for XML parsing in AirDC++:
https://github.com/airdcpp/airgit/commit/82e02ff9f7023a4aa5a35b61c4cd313b9fed59a6
The only issue I've noticed is that the default hublist
(http://dchublist.com/hublist.xml.bz2) won't pass the validation.
--
You received this bug notif
** Also affects: airdcpp
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1649066
Title:
Invalid UTF-8 data is not always being rejected
Status in AirDC++
Public bug reported:
There are various cases where invalid UTF-8 data is being consumed by
the core:
1. Text::convert will return the original string in case of errors (Linux only,
respective Windows-specific functions will return an empty string in case of
errors)
2. When using "utf-8" encodin
I'd be more strict with the allowed NSIS version:
https://textslashplain.com/2015/12/18/dll-hijacking-just-wont-die/
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1620100
Title:
NSIS 3
Status in
Apart from
https://github.com/airdcpp/airgit/commit/775bdc1fc1a58a2d0720cc4a8122f3e85897b8b6,
I haven't really made notable changes to detection-related code during
the last few years. I just noticed that there was a need to make some of
the functions a bit more "universal" after reading your detec
Yeah, automatic detection in AirDC++ won't do any port mapping because
of the reasons above. It's unclear to me that who's using NAT with IPv6
but I still implemented port mapping code for manual (experimental) use
since MiniUPNPc had support for IPv6. Maybe it can be used for opening
ports from th
** Changed in: airdcpp
Status: New => Fix Released
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1543595
Title:
Issues with encrypted transfers
Status in AirDC++:
Fix Released
Status in
** Changed in: airdcpp
Status: New => Fix Released
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1445330
Title:
CCPM and hub connection encryption
Status in AirDC++:
Fix Released
Status
Public bug reported:
1. Join an ADCS hub with at least two ncdc users
2. Download filelist from both users
3. Disconnect both connections
4. Download filelist from both users again
The second download will fail. I suspect that this is because ncdc
generates certificates with a hardcoded subject (
"while it successfully connects through IPv4 to other clients like
AirDC, StrongDC++, etc... (ones that have different IPv6 low level
socket code implementation than us)."
The low-level socket implementation in AirDC++ should be very similar as
in DC++.
"If it's enabled and the user doesn't have
See
https://github.com/airdcpp/airgit/blob/master/windows/DirectoryListingFrm.cpp#L1792
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1307313
Title:
ADLSearch can no longer show different files wi
Ah, but isn't KEYP meant to prevent connection hijacking, so even that
doesn't seem possible.
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1445330
Title:
CCPM and hub connection encryption
Statu
I understand requiring the CCPM connection to be encrypted but not why
the _hub_ connection needs to be encrypted. Because someone could snoop
the token that is sent through the hub and hijack the connection? The
same applies to encrypted transfer connections as well, but they can
still be establi
Public bug reported:
I don't understand that why does DC++ require the hub connection be
encrypted before the user can initiate CCPM connections. There's no such
limitation for encrypted file transfers and I don't see it being
mentioned in the extension specs either.
DC++ won't even disallow CCPM
When using a recent operating system, applications generally stay in
taskbar while they are minimized. Because of that, I'd assume that the
tray icon is mainly used for notifications or quick operations (i.e.
changing the limiter value) instead of minimizing/maximizing the main
window. Double-click
Only changing the search responses wasn't that complete idea as clients
will still less relevant replies if there is nothing better available :p
I also made it order the displayed search replies based on a combination
of the word matching scores and the number of hits. This also makes it
much easie
https://github.com/airdcpp/airgit/commit/c395d994b87f55c35a4584551d65a2c34df574a2
My implementation will also ignore partial matches from the parent
directory names if they are all less than 3 characters long (I can't
cases where such matches would be wanted). It won't go deeper when all
words are
** Also affects: airdcpp
Importance: Undecided
Status: New
** Changed in: airdcpp
Status: New => Confirmed
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/190964
Title:
Rare connec
It seems quite clear that the client should move on to other locations
when the list of search terms to match gets empty after matching a
directory name. But what should happen if there aren't enough matching
items to reach the maximum result count? Should it then enter those
fully matched director
** Also affects: dcplusplus
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1265889
Title:
Return more relevant search results
Status in AirDC++:
Confi
It doesn't, now the function throws if the IP is set :p
** Changed in: dcplusplus
Status: Fix Committed => New
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1245179
Title:
Resolving addres
It's still doesn't work in the same way as my original patch. Please
read this: https://bugs.launchpad.net/dcplusplus/+bug/309402/comments/23
It should try connect via both protocols according to the original idea,
and I'd say that it's worth of keeping like that (for some reason I've
had quite a
Or actually DC++ isn't able to connect to any NMDC hub but my patch for
https://bugs.launchpad.net/dcplusplus/+bug/1245179 seems to fix that
issue as well (when it's applied without poy's modification)
--
You received this bug notification because you are a member of
Dcplusplus-team, which is sub
I think I saw someone else reporting this as well, but now when I tested
it, everything to work just fine with AirDC++ and DC++
** Changed in: airdcpp
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to
... and what comes to the bug description, this is more about fixing
connections to IPv4 addresses when IPv6 isn't available/functioning
properly (it's not often the other way around)
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
h
my bad, even clearing the error wouldn't work, as one of the later
attempts may still set it (I've already forgotten what I was thinking
when I made that fix...). That fix is part of the latest stable versions
of AirDC++ and AirDC++ nano so I consider it to be reliable. The version
URL used by
Or the purpose of "lastError" was to explain that it only stores the
last error that was received... there may have been other errors as well
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1245179
Ti
The edit that you made is wrong so the problem remains.
If resolving the first address fails, lastError gets set. The client
will still continue with the other addresses and they may success, but
since the error was set, the function will throw. Maybe lastError isn't
a good name for it though. You
"In Progress: The assigned person is working on it."
Hmm?
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1245179
Title:
Resolving addresses with A and entries may fail in some cases
Status i
** Changed in: airdcpp
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/395400
Title:
Hub lists fail to cache on Linux
Status in AirDC++:
Fix Released
** Also affects: airdcpp
Importance: Undecided
Status: New
** Changed in: airdcpp
Importance: Undecided => Low
** Changed in: airdcpp
Status: New => Confirmed
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
http
** Changed in: airdcpp
Status: New => Confirmed
** Changed in: airdcpp
Importance: Undecided => Medium
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/363092
Title:
TLS port should not be
https://github.com/airdcpp/airgit/commit/d101c6a81ba7913a10867aa6a2063e50cb1abf09
** Changed in: airdcpp
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/39540
** Also affects: airdcpp
Importance: Undecided
Status: New
** Changed in: airdcpp
Status: New => Confirmed
** Changed in: airdcpp
Importance: Undecided => Low
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
http
** Also affects: airdcpp
Importance: Undecided
Status: New
** Changed in: airdcpp
Status: New => Confirmed
** Changed in: airdcpp
Importance: Undecided => Low
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
http
** Also affects: airdcpp
Importance: Undecided
Status: New
** Changed in: airdcpp
Status: New => Confirmed
** Changed in: airdcpp
Importance: Undecided => Low
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
http
** Also affects: airdcpp
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/363092
Title:
TLS port should not be allowed to be the same as regular ports
Sta
Ah... I missed the change in r3366 (which isn't the cheapest way to do
this).
New results with 10 million iterations:
Comparison (CID), took 19 ms
Comparison (UserPtr), took 22 ms
ClientManagerListener::ClientDisconnected(), took 427 ms
isSelf(), took 96 ms
(not that any of this would make a
Improving performance wasn't fully correct... but there's no actual
difference
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/309815
Title:
[Feature Request] Different hub icons for different user
1 - 100 of 163 matches
Mail list logo
