Pothead

Netgear have a really nice interface and are easy to setup and use. They are also have a problem prone to melting. Sweex have a really hard-to-use interface and are kind of a pain to setup and use. From what i seen of a m8's one, the hardware seems to be really good. Belkin are about average to setup. Have seen melted ones though. So i currently using Netgear but if i cannot get a warranty replacement if this one melts as well, i gonna get a Sweex next. Either that or stop being lazy and setup my old pc with Monowall on it. ;)

-- 0.701 2007-10-18 -- * Replaced yassl with OpenSSL, SSL certs no longer require external OpenSSL application Also maybe worth trying the latest DC++ on Vista to see if you have any success with that ;)

Are you using the adcs:// prefix or whatever you need to do to connect to an adc hub securily. ? Because cannot find latest beta source, not sure if the encryption code been updated to how it works in latest dc++ svn which changed and now works without users having to install external apps.

Thanks Satan, that's what i guessed in my router. Just was never 100% sure if i had guessed right or not. Nice to actually know. :whistling:

That's how i initially thought of doing it when requested of me, but i was lazy and didn't see the point of a second notepad. Someone else did it the copy paste method, and i used it ever since. lol.

About 3 minutes of copy pasting is all that's required. :)

Anybody if TLS needs a TCP, UDP port or both yet ? I fail at seeing that packet type to open in my routers firewall. :)

Strange how not showing limiting is now classed faking. Times change i suppose. I see Vi7o's point though, dumb ops kick for any limiting. An uncapped upload kills the internet for any other App \ Network user sharing same line. And unfortuantly a happy medium is impossible to reach, because some people abuse upload limiters. :)

me guesses clients without TTH, TTHL and TTHF support. So ones based on DC++ 0.401 ? or earlier not supported ? (just guessing version ## from dc++ changelog, which says TTHL was added in 0.402).

i completely agree. :D

/rebuild should fix it faster, since it won't require all the share to be re-hashed

Is the rest of the linux port code available for download, so can try compiling & testing porting the partial file stuff ? translated: for $260 i will give it a damn good try. And if i fail, i know others who won't fail. :thumbsup:

So what is NMDC Extended ? You mean clients with partial / full ADC support ? What is zport ? Never heard of that one before. As for ZLine and ZPipe . . . . ZLine was the initial idea of how to do it, ZPipe is the complete version. Hence ZLine is redundant. Use ZPipe instead. :huh:

Apparently steward has been doing for a long time. Hublist.org is being ddos'd by little children. http://dreamland.gotdns.org/PublicHubList.config.bz2 :wacko:

Just a comment about the Memory in Status bar request. Apparently the getMemUsage code which is commonly used in dc++ based clients is a bit buggy and can cause a random crash at some point. I've never had it happen to me, but i've heard it from quite a few different people. Having the memory usage updated every second or so (or how ever often the status bar is updated) increases the likely hood of the crash. Personally i like that feature, but that's also the reason it was removed from dcdm svn last year. :wacko:

More than likely your ISP. Best way i heard of checking is to try a torrent with lots of seeders. Check the speed you get when it's encrypted, and compare to how fast it runs when not encrypted. :)

That's from dcdm. Sulan made it. (he also made the Myinfo detection in Sasser, which dcdm uses) :(

ISP's install P2P software ? Wow, which country do you live in ? I gotta move there. Anyway, if they are incable of turning a computer off, or upgrading something, they shouldn't be using pc's in the first place.

If they like dwelling in the past, recommend the hub owners to install windows 3.1. Might suit them just fine. :(

Users with [VIP] prefix can easily be blocked in the hubsoft. Open to abuse . . . . . like if i send the welcome message. ^_^

That way is a really bad idea. Open to abuse, and a pain in the arse to code. And it floods your hub with welcome messages. Incase you don't understand that . . . . . [VIP]AUser [VIP]AnotherUser [VIP]SomeRandomUser And protect everybody with [VIP].

It's not the fact that he refuses to upgrade, which i would class as a stupid action. It's the banning people who do upgrade i find stupid.

You still won't know the profile levels. Only the hub knows them. The only difference the client can tell is between Op and Not Op.

That's for NAT problems, not closed ports. DC++ handles network addres translation fine. It you read the Technical specification, you still need to open a UDP port for that to work. :)

Plus the Apex cannot tell the difference between Registered Users and Vip Users. Or even unregged users (unless they are not regged in any hub). Only feasible way is to give all the vip's a prefix. And protect all the people with that prefix. :)