DC++

Just a note: I care for passive mode users, since I am one! =)

It could be limited in other ways.

1) require a special search be made to return metadata (maybe also require searches to be narrowed in some way)

2) Only return one or two results if they include metadata.

The dreamland list now supports bzip2 lists, as is evident from my sig.

Hehe. Ouch. Why dont you write a relayer? Or havent you alread? I know a bunch of people did that when I first talked about my list, I never saw anything released though. Thats exaclty what i did, a while ago.. I hope the IP is static :) dreamregg.hopto.org resolves to 213.226.69.87 and the patched...

a different matter here.. I don't know if you noticed this sandos, but I tried scripting the NMDC hub to register to dreamland - but it does not work. The remotehost is set for the winsock when it registers and is not read from the textbox in the hub but rather from a variable or something.. The on...

I would like to see the bitrate of mp3 files so that we have an idea of the quality of the files we are downloading. In general, metadata would be nice, such as bitrate, length, codec and version, hashes, any metadata that is extractable from different filetypes. This would, however, requiring a (s...

Sid wrote:I have had a similer problem to that. Most of the time my client logs in wiht out a problem but every now and again it hangs and the hub tempbans me. best i can come up with is there is a bug in the nmdc hub software.

-Sid

Happens to me aswell.

Hubs only protect the ip-addresses of passive mode users anyway, I think we should be able to get everybodys ip. That way, its more fair! ;)

I'd like to think there is nothing wrong with my hub , but looking at the dreamland hub list it comes out like this: hubname | adress in the description field C:5091 | usrnr | adress wonder, what is C:5091, alot of hubs have different numbers and a few have real descriptions... any info would be co...

ivulfusbar wrote:this is _impossible_ and can never be fixed.

Not quite, if youve got a SOCKS server able to accept incoming connections. The problem here is knowing other passive users´ ip-addresses, which is not possible with a vanilla dc-hub, but it might be sometime if one extension allowing this is made.

Someone could put a wiki up, letting everybody write to the rfc. Once in a while, someone then copies that to a "official" read-only rfc.

How about a UNIX port? Since you don't use any GUI code, it wouldn't be to hart to do a port to any decent UNIX flawor. Make it fork to the background and/or run as a inetd/xinetd service instead of a windows service. To run as a "inetd" service, it wouldnt have to do anything since inetd takes car...

Nev wrote: I have found that sending $jibberish <unknownparam1> ... <unknownparamN>| does not confuse either nmdchub, nmdc or dc++...

Yup, with some limit as to sizes, I cant remember if it was 8 or 16 or 32Kb, when the nmdc hub just discards it.

Yup, its nice.

=)

The hub could log, if you wanted (by issuing a command) every disconnect so that you can check when you log back in again what the reason for the disconnect was, could give clues as to the cause?

Now fixed. Only welformed hostnames are allowed now. Will also implement dupe-check soon.

If Arne decided, he could close the CVS and make the DC closed-source, pay-for version, since it's his program. However, since the souce code (before he'd have closed it) was released under GPL, he could not stop developement (also, he'd either have to remove all code that wasn't written by him, or...

aDe wrote:Good question. He never announced that he stopped - i think.
It was looking really good

It really did, but I imagine it uses alot of bandwidth.

Thats a tag the Ptokax hub adds, it seems to me. Not all versions though.

Wow, the list has been stalled for months without me noticing it! Only if you accessed the list at the alternative port 99 would it be fresh.

Ah. Yeah, saving the list at shutdown could be useful.

I'm currently writing a client side bot which will be used to get rid of nasties (such as fake share clients) that are hard to spot reliably with a sever side script. I'm not having too much trouble with it so far, though I do have one question for you guys. How should I deal with kicking offenders...

I dont get what you are talking about. DC++ keeps the hublist until you press refresh, whats this caching youre talking about?

If you have a old p120-ish box + 2 nics lying around, you can install linux + QoS. Linux can act as a bridge and also shape the traffic. Better use BSD if you intend to shape the traffic, it's easier. BSD+altq? Or do you mean bandwidth pipes that can be set in the firewall config? Altq always seeme...

If you have a old p120-ish box + 2 nics lying around, you can install linux + QoS. Linux can act as a bridge and also shape the traffic. I am planning to deploy one box just like this at our house´s very saturated 10mbps connection. Bridging means the box will work like a switch (it is in fact a ...

Looks nice. If a client never wants updates about other users (search bots, hublist bot), does it have to use the normal DC way of connecting then?

The source of the hublist running at http://dreamland.gotdns.org/PublicHubList.config is in cvs at https://sourceforge.net/cvs/?group_id=47459