SMT
Member-
Content count
70 -
Joined
-
Last visited
Posts posted by SMT
-
-
recent beta of flylink added it too
http://code.google.com/p/flylinkdc/source/checkout
let's support common stream format for all DC++ clients, so users will easily switch between clients without rehashing big files
-
Now count 52 059 * 20 = 1041180. So filelist will be larger about 1 MB. Download speed was 9.36 kB/s. So it will take 109 seconds to download this additional data.His filelist has 1.53 MB. It takes about 167 seconds to download
you "forget" bzip2 compression ))
every file have 74 bytes minimum (filesize=0, filename with single char), 100 chars typical.
so, his filelist would be 52 059 * 100 = 5 205 900
with timestamps: 52 059 * 120 = 6 247 080, just 17% increase
but timestamps will be similar to each other and much more compressible, than TTH. so really it will be less overhead than 17%
-
Do we can get the NAT ID from the frame?no. it can't be even discovered, does remote peer using NAT or have own IP
-
Let's try another position: TPC/IP frame contains the origin mac or NAT ID. Could you do the limiter "one segment^file at a time from one unique host" without any linking with nicks or IPs.there is no way to discover peer's MAC unless he is in the same ethernet segment with you
-
link to s16.3 source available here
<<removed>>
i have difficulties uploading to sourceforge because they terminated ftp access, only sftp. i tried latest winscp, but it does not accept my password
-
maybe some kind of ban for you on her client side. change nick (reinstall client, if using ADC hub) and try again
-
What is the problem with the code as it is? I wasn't aware of a bug, but i'm always glad of a fix, but what am I fixing?peer can't send search result when working through socks5 proxy
-
if(SETTING(OUTGOING_CONNECTIONS) == SettingsManager::OUTGOING_SOCKS5 && proxy) { if(udpServer.empty() || udpPort == 0) { throw SocketException(STRING(SOCKS_SETUP_ERROR)); } serv_addr.sin_port = htons(udpPort); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(udpServer.c_str()); string s = BOOLSETTING(SOCKS_RESOLVE) ? resolve(ip) : ip; vector<uint8_t> connStr; connStr.push_back(0); // Reserved connStr.push_back(0); // Reserved connStr.push_back(0); // Fragment number, always 0 in our case... if(BOOLSETTING(SOCKS_RESOLVE)) { connStr.push_back(3); connStr.push_back((uint8_t)s.size()); connStr.insert(connStr.end(), aAddr.begin(), aAddr.end()); } else {
replace it toif(SETTING(OUTGOING_CONNECTIONS) == SettingsManager::OUTGOING_SOCKS5 && proxy) { if(udpServer.empty() || udpPort == 0) { throw SocketException(STRING(SOCKS_SETUP_ERROR)); } serv_addr.sin_port = htons(udpPort); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(udpServer.c_str()); // string s = BOOLSETTING(SOCKS_RESOLVE) ? resolve(ip) : ip; vector<uint8_t> connStr; connStr.push_back(0); // Reserved connStr.push_back(0); // Reserved connStr.push_back(0); // Fragment number, always 0 in our case... if(BOOLSETTING(SOCKS_RESOLVE)) { connStr.push_back(3); connStr.push_back((uint8_t)aAddr.size()); connStr.insert(connStr.end(), aAddr.begin(), aAddr.end()); } else {
-
Outpost 3.5.x.xxx does not have problem. feature request: detect injected Outpost 4.x component (that has resource leak) and recommend to downgrage program version
-
there aren't... yes, there are implementations which almost work, but it's very easy to break it.
there is nothing to break. some crazy wants to simulate, that he can't download from me because have same share and ip as some other user?
-
finally i traced this old bug with every dc++ client crash on large memory block allocation.
the reason is Agnitum Outpost Firewall. his wl_hook.dll allocates some bytes
with alignment of 64K on every thread start
so, "virtual memory used" is not too much (60K of each 64K is free), but there
can't be another alloc larger than 60K
-
Thats all fair and well. However, it's not possible as previously discussed. Not under NMDC anyway.don't say "impossible", because there ARE working implementations
-
no, it's not... if two different files have same TTH, they have different sizeback to school, please.
if things will be so easy, there can be possible 'super-archiver', that compress *ANY* file (regardless of its size) into pair size+TTH.
and there will be a way to restore, because no another file with given size can't have same TTH, so we can restore exact hashed file
do you realize, that it's impossible to lossless pack DVD-image (or whatever) into 32bytes (24tth+8size)? =)
-
Pocket Applications =):
GSPlayer - music
TCPMP - video/anime
Haali Reader - books
GIS Russa - gps, maps
Nuclear time - game (fallout )
Crypt Quest - game (puzzle)
Nutcracker - game (metal gear )
-
FAR Manager - files handling, editing sources
Visual C++ - compiler
NuMega SoftIce - hacking
IDA PRO - reversing
Mapple - all math in one place, helps programming
Araxis merge - tracking revisions of open-source projects (thanks PPA for hint)
Maxthon - www
Download Master - http/ftp downloads
greylink - dc++ (features i can only dream. unfortunately, not open-src)
The BAT - mail
Miranda - icq
winamp - music (like this for plånty plugins for exotic formats, including chiptunes and synthesizers tracks)
GOM Player - video
ffdshow, haali splitter - codecs
Nero - DVD Burning
ACDSee 2.4 - image viewer (very fast and lightweight, exe 240kb and that's all)
Paint Shop Pro 4.12 - old and lightweight version of image editor
DJVU Reader
Daemon Tools - gaming
-
no, there's not a probability of collision because we use also size check, so it will always workthere is a probability of tth collision even for files with same size (if you didn't know it) =)
-
but it can happen and we don't play at "probability is low, so it can sometimes work"ha-ha, then don't use TTH hash because there is a probability of collision, and sometimes it will not work =)
well, it's your client and up to you to decide, implement user' requests or not.
but it is user' choice, which client to use =)
-
yes, hub in TransferView is just a guess from last ConnectToMe, but there is one thing... if user A tries to connect, then user B with same nick tries to connect and this user B connects faster, the user A will be dropped and hub of B will be displayed as hub of A. It¨s just current implementation of NMDC protocol.not big problem: user waits one minute before connections, but item in connection queue waits 1-2 secs (socket connect - socket accept)
with other unique things (IP, Nick) error probability is very low. its acceptable that second user in this rare case gots 'no slots' until 1st user completes his donwload
-
i agree that there is insignificant probability of mistake (if both users have save Nick, same IP, and connects with same time, 2-3 seconds delay for socket connetion accept). but it worths fixing hell with 15-20 actively used hubs in one local network
-
yes, you see share size in userlist, but you can't get share size of user who is connecting to you, just because NMDC doesn't have any user identification.Imagine this:
User A - shares 2 GB
User B - shares 3 GB
(both have same nick, but are in different hubs)
now user A is connecting to you, but it gets share size of user B
then user B is conencting to you and it again gets share size of user B, but connection to this user will be dropped
why i see "hub" in Trasnfer List, is it fake? user connection (afaik) initiates via hub commands "$ConnectToMe" and "$RevConnectToMe", so client knows nearest incoming connections came from
-
well. even if hub does not show share size (never meet this rare case), just don't restrict their users. but uploading to same user from different hubs is not good behavior, because it forces user to join as much hubs as possible. users that didn't join all possible hubs looses in download speed / waiting time. so it must be fixed
-
I don't see it so much correct, because you can't get share size of connecting users in NMDC hubs.i've seen only PtokaX (windows) and Verlihub (linux). both of them shows share size of every user when i connects to hub
-
what clients?PM-ed. "cheating" clients are forbidden to advertising here
-
it contains
string newName = aName + name + PATH_SEPARATOR; if((Util::stricmp(newName + PATH_SEPARATOR, SETTING(TEMP_DOWNLOAD_DIRECTORY)) != 0) && shareFolder(newName)) {
1st param of stricmp will be double-ended with PATH_SEPARATOR, so never matches with 2nd param
TTH in NTFS streams
in Feature Requests
Posted
i think, link to source code for this feature will be useful =)
here is a safe link:
http://www.hostingcup.com/jqscaupcwhbc.html