[Twisted-Python] Proposal: changes to reactor.clientTCP
glyph at twistedmatrix.com
Sat Jun 15 20:10:42 EDT 2002
From: Ivo van der Wijk <ivo at amaze.nl>
Subject: Re: [Twisted-Python] Proposal: changes to reactor.clientTCP
Date: Sun, 16 Jun 2002 01:06:51 +0200
> On Sat, Jun 15, 2002 at 06:04:29PM +0200, Itamar Shtull-Trauring wrote:
> > Background:
> > Ivo pointed out there's no way to differentiate between "no such
> > hostname" and "connection refused". For that matter, connectionFailed
> > has nothing to do with the protocol - why are we doing a callback on the
> > protocol at all? It shouldn't be created if no connection was made.
> > Proposal:
> > reactor.clientTCP accepts a protocol factory instead of a protocol, and
> > only makes a protocol instance if connection was made. Additionally, it
> > accepts an additional argument, failureCallback, which will get called
> > with a status code (CONNECTION_REFUSED, NO_SUCH_HOSTNAME) or something
> > when the connection fails. Protocol.connectionFailed goes bye-bye.
You know, I'm tempted to disagree with this because backwards-compatibility at
this point is a really major argument to me at this point ... however, you guys
make some really good arguments. It may even be possible, given this
description, to make __init__, and not makeConnection, be the real
"initializer" of a Protocol at this point.
The inability to report these errors has also been an annoyance on the
client-interface end of things for some time. There is an asymmetry between
client and server-side connecting in IReactorTCP.
In addition, Itamar's proposal would simultaneously eliminate the confusion
currently surrounding Connectors, too; having a wrapper protocol *factory*
would not pose the same efficiency concerns as a wrapper Protocol instance,
since indirection would only happen when opening and closing the connection.
> > Comments?
> Some people don't see a point in providing these errors, so I'll illustrate
> the issue with some more examples:
Also, being able to report these errors is important to judge at what level
networking is misconfigured for the end-user, when they can't connect.
> I agree with itamar that if these errors aren't handled in the protocol
> implementation, failure to connect shouldn't be there either.
After hearing this, so do I. Thank you for the bug report.
| <`'> | Glyph Lefkowitz: Traveling Sorcerer |
| < _/ > | Lead Developer, the Twisted project |
| < ___/ > | http://www.twistedmatrix.com |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20020615/96515692/attachment.pgp
More information about the Twisted-Python