Search found 306 matches
- 2003-07-07 18:40
- Forum: Programmer's Help
- Topic: Error compiling v0.251 in VS.NET 2003
- Replies: 1
- Views: 1721
- 2003-07-07 09:27
- Forum: Protocol Alley
- Topic: $ClientVersion <version>|
- Replies: 70
- Views: 48124
- 2003-07-06 18:43
- Forum: Programmer's Help
- Topic: Close hubs windows if..
- Replies: 11
- Views: 5111
- 2003-07-01 00:12
- Forum: Protocol Alley
- Topic: Dj_Offset's DCTNG
- Replies: 5
- Views: 3566
Dj_Offset's DCTNG
Dj_Offset produced an interesting reworking of the DC protocol ; it even lacks blatant spelling errors. It: Removes the silly lock/key system. Identifying clients is done with a command for that purpose, rather than hijacking a system that's spectacularly failed to keep unauthorized clients out of H...
- 2003-06-14 07:06
- Forum: Feature Discussion (Archived)
- Topic: DC++ NEEDS THIS!!!! (and it's something regular DC has!)
- Replies: 35
- Views: 14526
a little late but if you are still having any problems with rollback incosistency change the rollback to 0 in settings, for some reason rollback messes up sometimes in every program I've used to transfer. KaZaa, FTP, WinMX, Grokster, eDonkey, napster, ICQ, AIM, Messenger and a few others. Thanks fo...
- 2003-06-13 13:20
- Forum: Feature Discussion (Archived)
- Topic: New ICON for Dc++ VIP'z
- Replies: 23
- Views: 7764
- 2003-06-03 17:24
- Forum: Protocol Alley
- Topic: Encryption?
- Replies: 78
- Views: 91630
My main issue with SSL is that (1) implementing such a complex protocol oneself, especially when openssl has had such security issues and was written by more competent people than many in this thread (including me), is stupid., and (2) there are no GPL-compatible libraries for it I've found on Windo...
- 2003-05-29 00:41
- Forum: Off Topic
- Topic: I have been using DC++ since ...
- Replies: 17
- Views: 8625
- 2003-05-21 11:08
- Forum: Developer's resort
- Topic: [Joke] Dark side of the c pre-processor
- Replies: 4
- Views: 3347
Okay, for those who want to look at a slightly prettier version of the code: <fake prompt> cat blah.c | cpp | astyle # 1 "<stdin>" # 1 "<built-in>" # 1 "<command line>" # 1 "<stdin>" # 9 "<stdin>" char _DAH_[]="ETIANMSURWDKGOHVFaLaPJBXCYZQb54a3d2f16g7c8a90l?e'b.s;i,d:" ;main ( ){char * _DIT,* DAH_,*...
- 2003-05-19 00:51
- Forum: Feature Discussion (Archived)
- Topic: How to "pause" a download!!?
- Replies: 4
- Views: 2452
- 2003-05-13 23:33
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
So far, the general tone was "the more, the better"; which is true from a purely technical point of view, but becomes false past a certain point from a global point of view. The real question is : Where is that certain point ? Obviously, the distributed hub concept doesn't need to be scalable beyon...
- 2003-05-12 18:50
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
each slave hub handling 500 users Each slave must effectively handle 1,000 users - 500 clients, 499 other slaves, and the master. Thus, a connection which can handle 500 "users" will handle no end-user clients, but the 499 other slaves and the master, each of which will require as much bandwidth as...
- 2003-05-10 17:39
- Forum: Feature Discussion (Archived)
- Topic: Auto search and add new sources
- Replies: 31
- Views: 11120
- 2003-05-10 16:01
- Forum: Feature Discussion (Archived)
- Topic: Auto search and add new sources
- Replies: 31
- Views: 11120
- 2003-05-10 06:39
- Forum: Feature Discussion (Archived)
- Topic: Multistreaming
- Replies: 39
- Views: 13777
I figured if it was hard coded into the program that would force people to abide by the priority flag rules it would only work if it were with some form of nmdc... with dc++ being open source then those saavy programmers would be able to fake priority a flags on all their different sources so never...
- 2003-05-09 02:09
- Forum: Feature Discussion (Archived)
- Topic: Multistreaming
- Replies: 39
- Views: 13777
they are guarenteed 1 slot by priority if someone elses slots are taken up by multisourcers. What mechanism guarantees them this? It could work... it really could... Sure, if people suddenly ceased being selfish. And as for the switch that hub owners could turn on and off... that was for the "leech...
- 2003-05-08 00:17
- Forum: Feature Discussion (Archived)
- Topic: Multistreaming
- Replies: 39
- Views: 13777
This is precisely the type of suggestion I had hoped to avert with my previous post (read the last couple of paragraphs of that to see what I mean). Its fundamental flaw is that is relies on users to voluntarily relinquish slots, when they have no incentive do to so, and plenty of incentive to keep ...
- 2003-05-03 14:55
- Forum: Feature Discussion (Archived)
- Topic: Seach.File Type: >Any Non MP3 file<
- Replies: 16
- Views: 6198
Because currently search requests are non-deniable. This behaviour is implicit in the protocol, but more importantly are implemented with stupid bots on the hubs. No search results from certain search requests - too bad, then you must be using a leech client. Unfortunately, I think it is "too late"...
- 2003-05-03 14:45
- Forum: Feature Discussion (Archived)
- Topic: Auto Send IP to: Connection Setup
- Replies: 1
- Views: 1203
Thesetwo threads contain further information, and may answer your question. Please read them before further commenting. (Search for UserIP to find others.)
- 2003-05-03 14:34
- Forum: Feature Discussion (Archived)
- Topic: Slots Dedicated To A Hub?
- Replies: 3
- Views: 2054
This thread discusses the issue at length, though as a mandatory 'feature'; I would imagine the responses to its being optional will be different.
- 2003-05-03 02:43
- Forum: Feature Discussion (Archived)
- Topic: Multistreaming
- Replies: 39
- Views: 13777
How about limiting the ability to download a file from multiple people to around two or three total. I think even just that would be a big help. If this feature makes it in, no such limitation will stick - don't plan for it. FIrst if this enabled all download slots and such control is handed over t...
- 2003-05-01 16:54
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
You can´t just discuss in one topic a change of a protocol, The way your all talking is a whole new p2p network. Not if the extra messages among the hubs necessary to maintain the multihub network are filtered out before the users ever see them; in that event, the client can't distinguish this v...
- 2003-05-01 05:29
- Forum: Feature Discussion (Archived)
- Topic: “Close connection� available only to “Grant
- Replies: 10
- Views: 4167
- 2003-04-30 16:31
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
If we have multiple hubs, every hub sends its chat/search/myinfo and whatever to the other hubs, and then that hub has to send that to it's connected clients. Every hub will send out more data, requiring more bandwidth and we have not solved the bandwidth issue, rather the contrary. A multihub netw...
- 2003-04-29 19:48
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
The hub will need to have (for say 500 users/per hub): * Roughly 256 MB of RAM for uncompressed filelists in RAM It wouldn't store filelists, per se; what it really needs is a mapping from hash values to lists of users. * Recieve filelists if anyone connects or does a "/refresh" It should receive a...
- 2003-04-29 06:33
- Forum: Protocol Alley
- Topic: Metadata support in the client-client protocol
- Replies: 6
- Views: 3618
- 2003-04-28 17:57
- Forum: Protocol Alley
- Topic: Metadata support in the client-client protocol
- Replies: 6
- Views: 3618
Metadata support in the client-client protocol
The best suggestion I've heard to far involves: $Supports <blahblah, the usual DC++ supports> Meta <additional specific metadata types supported>| for example, neglecting the blahblah parts: $Supports Meta TTH| where TTH is tiger tree hashing. One more new client-client command seems necessary: $Get...
- 2003-04-28 17:45
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
We can stay online for almost 24 hours with over 1000 people. There are some stability problems, but it seem to work a bit now:). This would seem to argue pretty strongly that client knowledge/involvement is not, in fact, necessary. The PtokaX guys told, they could imagine the thing, but they also ...
- 2003-04-26 13:56
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
Change #1 is obviously needed in the client, since in the normal protocol the client only listens to the Server IP. It is impossible for another IP(computer/connection) to send the search request to the client, as they would not be recieved. (not even sent). Which is as it should be: clients connec...
- 2003-04-26 11:09
- Forum: Feature Discussion (Archived)
- Topic: bitrate
- Replies: 14
- Views: 4755
- 2003-04-26 09:35
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
Could someone explain again what the role of the client is in relaying? If you want to involve it in any substantial way in this, I'd like to see much more acknowledgement of the security issues. Further, much as it kept getting brought up, I see absolutely no need for any client-side modifications:...
- 2003-04-26 09:17
- Forum: Feature Discussion (Archived)
- Topic: Automatic search list
- Replies: 15
- Views: 6105
- 2003-04-26 09:06
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
- 2003-04-25 09:55
- Forum: Feature Discussion (Archived)
- Topic: “Close connection� available only to “Grant
- Replies: 10
- Views: 4167
Read this thread before commenting further, for the sake of not forcing people to spend time repeating old arguments, please.
- 2003-04-25 03:22
- Forum: Protocol Alley
- Topic: Idle thoughts about IRC
- Replies: 2
- Views: 1913
- 2003-04-24 23:02
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
But, another solution that keeps in mind the availability of more CPU and memory would be to do some of the tracking on the hub. Some say it's a bad idea legally to track filenames and locations on the hub, but it's very much a grey area. I'd say a good compromise would be to keep track of hashes o...
- 2003-04-24 22:03
- Forum: Protocol Alley
- Topic: Idle thoughts about IRC
- Replies: 2
- Views: 1913
Idle thoughts about IRC
I notice a tendency here among some to want to recreate IRC, to some degree. I've been toying with the idea of just going all the way with that and implementing DC-on-IRC as a set of modifications to IRC clients, with the following changes: Nearly the entire client-hub protocol is ignored, and the I...
- 2003-04-24 21:29
- Forum: Feature Discussion (Archived)
- Topic: About downloads limit…
- Replies: 41
- Views: 11971
the advantages for hub newcomers and users not on super-fast connections Users on faster connections should be able to open more download connections - they can better handle the bandwidth it'd use. Restricting the number of download slots a user has will result in suboptimal slot usage on the hub ...
- 2003-04-23 09:28
- Forum: Feature Discussion (Archived)
- Topic: About downloads limit…
- Replies: 41
- Views: 11971
I'm claiming that ops on the DC network have shown a tendency to exert as much control as is practical. If DC++ were to allow them to expect users to display their download limit, many of them would apply similar reasoning as you that it's something else about which they can make a rule, so why not?...
- 2003-04-22 16:25
- Forum: Feature Discussion (Archived)
- Topic: About downloads limit…
- Replies: 41
- Views: 11971
To me a DL slot indicator is merely a means by which to offer more options for OPs to choose from in how they decide to run their hubs I don't want ops to have an expectation they can run their hubs in some manners. I think all users have a right to keep their DL slot info private if they so desire...
- 2003-04-22 14:45
- Forum: Hubs and scripts
- Topic: Next generation of VB hub scripting
- Replies: 58
- Views: 18277
- 2003-04-22 14:23
- Forum: Hubs and scripts
- Topic: Next generation of VB hub scripting
- Replies: 58
- Views: 18277
$UserIP or $MyIP what difference does it make, he's supporting both. I would prefer to keep the size of the protocol hubs and clients are expected to support small (if MyIP doesn't catch on, it's relatively useless; if it does, it's yet more redundant baggage that has to be implemented by anyone wa...
- 2003-04-22 13:04
- Forum: Hubs and scripts
- Topic: Next generation of VB hub scripting
- Replies: 58
- Views: 18277
Conflicted here - I recognize this as something of a tangential topic to the thread, but not really substantial enough for a new one. Oh well, anyway: http://dev.direct-connect.nu/dcext/ lists some software which supports $UserIP - it's slightly more supported than MyIP, but more importantly, it's a...
- 2003-04-22 12:20
- Forum: Hubs and scripts
- Topic: Next generation of VB hub scripting
- Replies: 58
- Views: 18277
- 2003-04-22 12:17
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
On some ocassions we had to reset the router too. Um, you weren't running the hubs on the same connection, behind the same router, were you? That'd be kind of useless... With an advanced relayServer it would be possible, that it could act as a HUB. Clients could simply connect to it, every command ...
- 2003-04-21 23:47
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
How does the bandwidth usage break down more specifically? About how much is used by each of searching, chat, and administration? Argh, stupid Java implementation hung IE on the Mac just now, lost an almost complete post. Anyway, I'll try to do more than glance off the question: Total messages: bun...
- 2003-04-21 04:47
- Forum: Feature Discussion (Archived)
- Topic: Seach.File Type: >Any Non MP3 file<
- Replies: 16
- Views: 6198
- 2003-04-20 18:24
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
1. (The easier one...: Hubs shouldn't let users/clients be relays, Hub owners should setup relay servers and let some users connect to them. Okay, I have no issue with this, but it sounds much more like what I suggested anyway than this system of, for example: $Supports ... DDCP| $ddcReady2Relay 12...
- 2003-04-20 17:59
- Forum: Feature Discussion (Archived)
- Topic: Reporting Clients
- Replies: 12
- Views: 4684
No, Clients cant be trusted. You are asumming that people would naturally want to report others. Trusting a client is like trusting another human being to be honest. Huh? Yeah, clients can't be trusted to act kindly towards other clients competing for slots; if provided a way to say "look, evil cli...
- 2003-04-20 05:26
- Forum: Protocol Alley
- Topic: Distributed DC network
- Replies: 72
- Views: 32712
HaArD: we not only want to connect the chat, but tu expand the maximum user limit on the HUB. The linux HUB, which we are running now supports this thing, the problem is: each HUB runs well with 600-900 users, but in linked mode each can hold just a few hundred, above that they get out of sync in j...