SMT

what about splitting ApexDC++ into 2 separate parts: daemon (service) and GUI? daemon will download/upload data and will be easy compiled to linux or other platform with std c++ libs from same sourcecode base. control must be performed from usual tcp/ip connection, so user can do anything remotely or control downloads on linux server from desktop pc with windows. gui for simplicity can be started at WINE (some apex mods altered to work in WINE), but later it can be rewritten as native linux application today ApexDC++ source is already split into 'client' and 'gui' library, but there is no strict interface it's also could be 2 lib-files for linking with gui 'StrongDC.lib': usual 'client.lib' that after linking creates monolith program and 'client.lib' with stub functions, that connects to real 'client.lib' on other process or remote machine, so it will be compile-time option to create monolithic or modular program even for windows users separating gui from server code will increase stability what do you think? too much work?

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

i think, link to source code for this feature will be useful =) here is a safe link: http://www.hostingcup.com/jqscaupcwhbc.html

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%

no. it can't be even discovered, does remote peer using NAT or have own IP

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

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 to 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)aAddr.size()); connStr.insert(connStr.end(), aAddr.begin(), aAddr.end()); } else {

peer can't send search result when working through socks5 proxy

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

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

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?

don't say "impossible", because there ARE working implementations

back 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

there is a probability of tth collision even for files with same size (if you didn't know it) =)

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 =)

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

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've seen only PtokaX (windows) and Verlihub (linux). both of them shows share size of every user when i connects to hub

PM-ed. "cheating" clients are forbidden to advertising here