Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 23 de Febrero de 1.999 - Martes
Message-ID: <358EE00C.816B5E51@argo.es> Date: Mon, 22 Jun 1998 22:51:56 +0000 From: Jesús Cea Avión <jcea@argo.es> Organization: Argo Redes y Servicios Telematicos, S.A. To: clientserver@dal.net Subject: [CS] More delayed replies References: <199806131246.OAA26357@corinto.argo.es>
In chronological order:
Please, read the entire message before reply.
[Telnet/PPP]
> So what's your opinion on the two ?
I see PPP scheme more "clean" and flexible. Implementation is easy. I had done it (Telnet too :).
> > Clients
> > can issue a "protocol" negotiation when:
> >
> > 1. There is no negotiation in progress (initial connect).
> > or
> > 2. Server answered the last "protocol" challenge, accepting it or
> > denying it.
>
> What about:
> 3. At some other time later during the client-server session after the
> client has registered.
Yes, that's is implicit in 1 and 2. If your negotiation has finished already, 1 is true (there is no negotiation in progress) and 2 is true too (server answered the last "protocol" challenge).
> If it were truely stateless, this should be possible.
Yes, it is.
> IMHO, a server should not be negotiating tablesize for compression.
> It might tell the client what it is using, but negotiate - No.
My point is... Why do you negate that possibility?. Yes, most of the time servers use fixed parameters but you don't know if next week somebody could propose a parametriced option. Since allowing parameters is not a problem, I don't see why forbid it.
> I really can't see the need for this sort of negotiation. The aim
> is to turn on or off options, not attempt to "tune" things.
Why not?. If the worst cases, client, server or both could choose among a fixed set but, why to limit "a priori"?. If you don't support an option or parameter, just reject it in the client-server negotiation.
[Changing the protocol along the link lifespan]
> This is a Bad Idea(tm). The protocol negotiation should be at the
> very beginning - before the registration - and it does not have to be
Most of IRC "parameters" can be changed along the link lifespan. Nicknames, for example. Yes, allowing protocol negotiation in the very beginning is easiest. I agree. But you lost future posibilities.
In any case clients nor servers are required to support this feature. In fact, they are not required to support "protocol" at all.
To keep the protocol asyncronous, the easiest thing to do is to keep two separate switches for each link: sending options and receiving options. When the server agree in the protocol negotiation, it changes its "sender options". "receiving", nevertheless, doesn't change until the client replies "ACK". In this way there is no blocking.
If a server/client doesn't want to renegociate the protocol, it simply refuses.
[Grouping options]
> My problem is that the clients will always request the full list,
> and as such using a lot of unnecessary bandwidth.
You are absolutely right, Carlo. But the initial "MOTD" is also bandwith wasteful and, worse, most users/scripts skip it.
> You will also understand that the above won't work: Client that
> request both esnet:zlib and esnet:crypt-blowfish64 will never ever
> switch to esnet:secure if they don't have to (client coders don't give
> a damn about bandwidth usage ;) (hi client coders). An IRC network
> would add the option "esnet:secure" and simply nobody would ever
> use it. You'd also never be able to drop the esnet:zlib or
> esnet:crypt-blowfish64 due to the demand for backwards compatibility
> (and due to the fact that nobody starts to use the esnet:secure
> option thus). While, when adding a few new features and calling that
> a new protocol - I am sure the client coders will upgrade their
> code to support the new protocol (as will be described in detail
> on the webpage etc).
Well, in ESNET we'll drop superseted options without any problem };-) to move forward, but you are right. In any case your schema doesn't solve the problem. Old clients would use old options forever.
A possibility, as I propossed the first time, would be TO DO NOT publish server options. Clients simply request features, and servers agree or deny them. In this way, a server could support 1.000.000 options. Clients don't choose. They only request its own supported features.
> number of cases where one side waits for the other's info before
> continuing should be minimized. But we already have one with the
> initial registration: the server doesn't do anything until it gets
> "NICK" and "USER" from the client. So the obvious way to keep as much
> asynchrony as we can would be to have the client send its own
> "PROTOCOL" command before registration, and the server send its own
> once the client has registered.
Yes, correct. But the point is... If you can design a protocol which can accomodate dinamic link protocol negotiation and parameter negotiation, why do not do it?.
I see the CARLO's concern about "option explosion" very valid but I completely disagree about the hierachical structure you propose. We, in ESNET, use Undernet code as base, but I'd like to patch my server to support DALNET options if they are handly. In this way, a "protocol:undernet 1.0" would be restrictive.
> S: PROTOCOL undernet 1.2 2.0 2.1 2.2 2.3 3.0
In ESNET there is no an unique "protocol". We borrow things from a lot of networks. And we extend the protocol in our own ways. Distributed databases for nick registration are in service since last week, for example.
I see the process VERY simple:
Servers could support 1.000.000 options without bandwidth overhead...
I'd rather prefer to drop old options favouring "grouping". That is, in ten years we'll have tons of options negotiated by 99.95% clients. Time to "group", sure. A year later ESNET'd drop support for "grouped options". That is, they could only be accesible using the new collective name.
Updated clients would run fine. Outdated clients... well, they'll lost adquired features (let say... compression). Their negotiations would be refused and the protocol negotiation would ends in "no option at all", using RFC 1459 directly.
If users start to lose "adquired features", they WILL upgrade their clients.
> I really don't like the idea that a protocol can be changed later,
> that can lead to a lot of "desync" problems between client and
> server and will make things needlessly difficult.
If you code using "sending" and "receiving" switches, like I explained before, you can't have desynch. In any case, the server and/or the client could refuse to negociate options again. That's an implementation issue, not a design issue.
[Grouping]
> I agree that it makes a difference that clients will always exactly
> know everything about any option they know, which is something that
> we should take into account, because it will save bandwidth. However,
> this bandwidth saving is exactly that: "grouping"... using one word
> for what previously was a whole list of words.
We both think equal. Instead of sending the options, they can be "merged" into a single option in two years, for example. Old clients work and new ones work also... using less bandwidth in the negotiation.
I agree.
> Now suppose that the registration is something that is protocol option
> dependend. Then a client can't proceed with the registration until it
> understands that the server won't respond on the /protocol query. Do
> you suggest a timeout?
You are right. There is a interoperativity minimun for all IRC servers.
Timeouts are a very bad idea.
> I have no solution for this :/ - except using a timeout in the case
> that the server doesn't support the PROTOCOL msg (and isn't our aim
> that ALL irc networks WILL support it - so maybe this isn't too bad
> a kludge).
This is an issue ONLY if you FORCE protocol negotiation along the initial registering. If you allow negotiation anytime your problem vanishes.
> For example, it may not be possible to change your crypto algorithm
> in the middle of a session.
Since we are not talking about "concrete" options, I insist: Client/server could refuse to renegociate options anytime. That is an implementation issue.
For example, PPP standard allows EXPLICITALLY options/parameters renegotiation (almost) anytime. Concrete implementations (Microsoft, for example) can choose to REFUSE changing any setting when the initial negotiation is over.
That's an implementation issue. We are designing an abstract protocol.
> Afterall, these options are a property of the server-client connection
> only and make no difference to anyone else except for the client
> involved.
I agree.
> Nevertheless, the problem is clear: If a New Style client connects to
> an old server, then the client seems to have to wait a while - a
> timeout. We don't want that.
Yes, we don't want that.
In a asyncronous world like current IRC:
Later, the server replies "protocol ACK". Then, it sends the new data to client using the agreed protocol.
So, if the server DOESN't support "protocol" either, client can progress.
Protocol negotiation is asyncronous.
:))
> Undernet will NEVER support to change protocol during a session, I
> simply see no reason to do that.
Fine. Nice. No problem. You simply refuse to renegociate options. That is your server right. I agree. I want a protocol which allows such a view. So do you, for sure.
> Replacement of the load of QUIT messages in case of a net.break by
> a single 'NETBREAK' message
Wow, nice idea :-p.
As I said before, nobody force you to renegociate options again after a client-server agreement is acomplished.
[Last ACK client->server]
> Yes, it does. It is redundant information.
> The client has made a request, the client receives the ack so
> now it knows that the server has agreed.
Carlo is right, Darren. For example, if client requests "compression", it can't switch inmediatelly because server could choose to reject it. When the client receives the server ACK, if now knows that comming information from server comes compressed. But since server DOESN'T know WHEN the client knows if the server AGREE OR NOT, it doesn't know when the client will start compressing... until it sees a message comming from client saying "I now know you agree about "compression"; I start compressing just now".
That message is the last "client ACK".
> With "networks" I mean "developer groups". "networks" that just use
> the source tree of one of the developer groups is not a seperate
> network in that sense.
That point of view is wrong if your network is "undernet based" but you "import" features from IRCnet, Dalnet, or Efnet. Since ESNET is a small network I don't expect client coders support "local features". But I'd like to use the undernet compression schema and the ircnet crypto protocol in ESNET simultaneously, for example.
> | To me, a "protocol" is just a macro; say, "undernetv3" could expand
> | to "zip, whisper, client-side-split-handling", while "efnetv2" could
> | expand to "zip, sslcrypt, multiple-modes-on-namesreply", and
> | "ircnetv1" could expand to "zip, join-ops-with-ctrl-g".
>
> Exactly
Oh, I see. So I could have "undernet1, efnet3, ircnet2" simultaneously in my network, couldn't I?.
> The client that was written for "foobar" never heared
> of "manfrotto", and thinks it is incompatible - which
> doesn't have to be!
Uhmmm... Good point, Carlo!. But since "foobar" is a "manfrotto" subset, your server could choose to support "foobar" negotiation, implementing the result using "manfrotto" code.
> Point 2. is a pain in the ass for the server coders,
> needing to be backwards compatible is one thing, but
> keeping a complete copy of the old code in the server
> to mimic two (or more) types of behaviour is something
> different.
If when you upgrade "foobar" to "manfrotto" you choose to keep compatibility with "foobar" clients, your server needs such code already. If "boobar" is a "manfrotto"'s subset, the code is already present.
> Well, I spend a lot of time explaining it - hope that it is clear
> now why we need a version number...
Yes, I see your point. A server supports options below its version number. No problem.
In fact... if you allow integer parameter negotiation, you are done!. Wow, a flashing idea :)
That is:
C: protocol undernet(15) {A new client}
S: protocol undernet(12) {an old server}
C: protocol undernet(12) {Client understands 12}
S: protocol ACK
C: protocol ACK
or
C: protocol undernet(12) {an old client}
S: protocol ACK {Server is >=12}
C: protocol ACK
or
C: protocol undernet(3) {a really old client}
S: protocol undernet(7) {Server rejects a protocol below 7}
Since Client can't talk undernet(7) and server can't talk undernet(3), client go on without any negotiation (RFC 1459 pure :). If undernet>=7 is mandatory, server blocks the client (but, normally, would be the user who disconnects).
Perhaps a bit overkill, but now Darren has an example where integer negotiation could be useful :).
> All I want to get everyone to agree, and get a standard.
>
> If there are people out there still reading this: Speak up
> if you agree with me; this discussion is so far only between
> Darren, Roger and me, and I will personally come to break
> your arms if in the end you refuse to implement what is
> being designed here if you did't participate in the dicussion ;)
As I said in my previous post, I am having a very busy time :).
I think is time to "clean up" the discussion. Somebody (I offer my time :) must do a proposal, noting all messages posted along the issue. The proposal must be sent new week, for example. List members *MUST* point out flaws and suggest extensions. Not "I don't like that feature" must be allowed without a rationale behind.
> I don't have a strong opinion for or against grouping.. I don't see a
> huge need for it, but I don't see it as breakage either.
If you allow integer negotiation, you can have "grouping" later "by free", as I just wrote.
Time to move on, folks. I'd like to discuss "integer negotiation" for grouping a bit more. Of course, almost anything is "optional", and Darren could choose to do not implement grouping in his server, the same way Carlo wouldn't implement protocol renegotiation in undernet. In any case, it's time to move on.
God, I almost flushed my inbox. At last!!! :)).
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
