In another thread I briefly touched the subject on what is protocol compliant and what's not. I'd like to extract some key notes from that thread, bake it with some other thoughts I have, and make it a topic on its own. As there are many hubsofts in progress but still very few clients, with dc++, and its offsprings, as the major player; I think this is the forum for it.
While hubsofts and clients are blooming, so are people trying to write specs about the dc-protocol. Most of the specs I've seem is more or less some ripp-off of big_daves excellent spec @ http://www.lwave.ca/dchub/protocol.html , for which I am so greatful for its existance.
However, while reading the formentioned specs, or while monitoring traffic between nmdchub and nmdc, there is times that I assume too much about the order of things.
A typical handshake when monitoring the traffic between nmdchub and nmdc suggests that $GetPass is in reply to $ValidateNick and that a $LogedIn is sent i just before and in conjunction with $Hello. Sometimes when pondering about the protocol I easily forget myself and make rules of these observations.
Guess what? There are no such rules!
I can send $LogedIn after I receive $MyInfo and that is fully compliant with the protocol. I can send $GetPass just about anytime I want and the clients totally accept that and replies with $MyPass.
Actually, the protocol is quite forgiving.
I have many many thoughts on this subject, also a couple of ideas on how to treat the protocol and on how to continue extending it. I'd be happy to share my thoughts, but it's more fun for all of us if I stop here and let others express their thoughts.
protocol compliance
Moderator: Moderators
Hmmm.. Well my thought....
Is that with the new hubs and client software that isn't NMDC they are overtaking the use of the NMDC and NMDH. I am not saying that we should go and do our own thing, but the protocol is going to be defined by what is mostly in use.
That being said, I think as that happens we can start defining the protocol as the main developers of the software that is being used the most see it. Hopefully, of course, in cooperation.
If say only 20% of users use NMDC and 5% of hubs are NMDCH then if we make the protocol more ridged and it breaks down NMDC because its expecting high tolerance, so what... The reason we would make extentions and the protocol more ridgid would happen if the developers writting the majority software has already picked the issue to death (that happens around here!) and decide it would make the protocol better.
If percentages of the Neo Moduleus usage was substantially low then I don't think we need to worry about breaking the protocol that is defined by the NM software, because it would (sadly?) not be missed to any great extent.
End this part of the post
============================
Now.. IF we wanted to see how rigourous the protocol is defined up against a NMDH than it would be really easy to program some quick VB program that allowed us to test things such as delays between commands, sending commands split into diffrent tcp blocks, mix the order of login commands and such.. and throw that through a linux box with tcpdump, we ccould become pretty darn sure how flexiable it really is and what is really expected. I'd volunteer, but I don't have VB or a system with windows to put VB on.
Ok maybe I missed the point, but my thoughts fairly ignore points and go about their own way... I hope others reply more coherently than I!!
Thanks for the Thread,
Moch
Is that with the new hubs and client software that isn't NMDC they are overtaking the use of the NMDC and NMDH. I am not saying that we should go and do our own thing, but the protocol is going to be defined by what is mostly in use.
That being said, I think as that happens we can start defining the protocol as the main developers of the software that is being used the most see it. Hopefully, of course, in cooperation.
If say only 20% of users use NMDC and 5% of hubs are NMDCH then if we make the protocol more ridged and it breaks down NMDC because its expecting high tolerance, so what... The reason we would make extentions and the protocol more ridgid would happen if the developers writting the majority software has already picked the issue to death (that happens around here!) and decide it would make the protocol better.
If percentages of the Neo Moduleus usage was substantially low then I don't think we need to worry about breaking the protocol that is defined by the NM software, because it would (sadly?) not be missed to any great extent.
End this part of the post
============================
Now.. IF we wanted to see how rigourous the protocol is defined up against a NMDH than it would be really easy to program some quick VB program that allowed us to test things such as delays between commands, sending commands split into diffrent tcp blocks, mix the order of login commands and such.. and throw that through a linux box with tcpdump, we ccould become pretty darn sure how flexiable it really is and what is really expected. I'd volunteer, but I don't have VB or a system with windows to put VB on.
Ok maybe I missed the point, but my thoughts fairly ignore points and go about their own way... I hope others reply more coherently than I!!
Thanks for the Thread,
Moch
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Endgame
Well, this is what I have in my mind whenever fusbar mentions "RFC." Test the software to see how it works and how it likes things... and document it. If ASH and DCH++ and Ptokax want to go a different way, well, hopefully everyone can agree on a single set of rules to play by.Moch wrote:Now.. IF we wanted to see how rigourous the protocol is defined up against a NMDH than it would be really easy to program some quick VB program that allowed us to test things such as delays between commands, sending commands split into diffrent tcp blocks, mix the order of login commands and such.. and throw that through a linux box with tcpdump, we ccould become pretty darn sure how flexiable it really is and what is really expected. I'd volunteer, but I don't have VB or a system with windows to put VB on.
Oh, and you will have to test both the VB NMDCH and the Objective-C OS X NMDCH as well. If someone needs an OSX box to test against, I can volunteer mine. (The sidenote to this is that NMDC itself changes at least slightly between Win and OSX, noticably that Jon no longer supports $Cancel on the mac client, and might not therefore support it in the next windows release.)
ASH will not be the hubsoft that goes astray. However ASH do pend on the fact that GetPass is accepted after MyINFO have been sent from the client. This is also important when it comes to the implementation of QuickList.
All I'm waiting for now is for ivul arne to block this just to watch me suffer.... =)
All I'm waiting for now is for ivul arne to block this just to watch me suffer.... =)
[url=dchub://ancient.myftp.org]ancient.myftp.org - [BBB][Sunet][Tele2] ONLY! @ 20GB (ISP/IP/Share Scripted)[/url]