Shareaza Concerns

[Toast]

Well i've seen that the Shareaza wants to implement ADC into their client so has the DC community and protest are already coming in over the wire.

The main concern is that it will be another MLDonkey disaster (NMDC Client), I'm not saying that a multi p2p client is bad just depends on how is doing the implementation and how much they respect our rules and our advices.

I do hope that the developers of this application registers and ask question if they face a problem or don't understand something in the protocol.

Another personal concern i have is the tag they are going to use and how slots are going to work is it shared with the rest of the application or one protocol at the time cause if its a 1/per protocol speed is going to be an issue and if its a shared slot system waiting time for a free slot is going to a be an issue.

So i really hope that we get a good start if they want to make this a reality with a proper discussion at this forum.

[Crise]

I don't know for sure since I haven't followed the project in ages... but at least regarding slot distribution I would assume that has to be separate (ie. own slots for DC and other networks) if this even comes reality. Because the DC slot system is well different would be the correct word I guess.

As for speed concerns well with multi network p2p apps upload speed on individual network is seldom optimal (ie. in other words available upstream is not allocated evenly between networks, so upstream is not guaranteed, and the more there are networks the more of an issue this will be).

Regarding the tag, there is no tags in ADC, just VE and other params... but that should not be any real issue as long as someone realizes that unique VE should be used isntead of DC++ "++ [version]".

[Dj_Offset]

There is no such thing as guaranteed slots, or upload speed? That is just wishful thinking (at best) of certain hub owners, that has manifested itself into lists of clients accepted and not for simply including bandwidth limiting.

There are plenty good reasons for having bandwidth limiting, and there is nothing a hub or a hubowner realistically can do about it without going down that slippery slope of denying unknown clients once again. OK, we did that once, and now all clients call themself DC++, even the ones that arent - that was useful!

In all fairness, any client who speaks compliant ADC should be able to join any hub, that's my take at least.

[Aqualung]

IF the proposed client behaves in exactly the same way as a dc++ client then there will be no problems,if it doesnt and compromises are made then it wont be accepted and hubs will ban it.

It is a massive undertaking to attempt this and keep on top of the security aspects of any software of this type,i wish the programmers good luck and will be interested to see the outcome if it gets further than an idea.

A dialogue at dev level is extremely important and i hope shareaza devs would understand this.

[Toast]

Well i hope that clients doesnt use emulation features on ADC since it is a new page in Direct Connect development

[Pietry]

One doesn't have to care what DC++ does or does not. The protocol is important. ( actually dc++ misses a lot of ADC features or they are poorly implemented ). A hub should kick clients out if they don't respect the protocol, not if they don't behave like DC++.
A client should not be discriminated by VE string, but by what it supports ( SU string ) and what it does or doesn't.