Ticket #2060 enhancement closed duplicate

Opened 8 years ago

Last modified 4 years ago

Generic IAddress connect and listen methods.

Reported by: rwall Owned by:
Priority: normal Milestone:
Component: core Keywords:
Cc: rwall, dreid Branch:
Author: Launchpad Bug:

Description

It would be useful to have a convenient way of calling appropriate reactor.connect/listen methods based on an IAddress implementation.

Kind of related to #1442.

Attachments

iaddress-connect-listen.diff Download (5.4 KB) - added by rwall 8 years ago.
connect-generic.py Download (1.0 KB) - added by rwall 8 years ago.
A simple example of usage.
iaddress-connect-listen2.diff Download (9.7 KB) - added by rwall 8 years ago.
A updated diff requires reactor to be passed as an argument and without redefining backlog default value; plus an SSL option, thanks to exarkun and tv for ideas.

Change History

Changed 8 years ago by rwall

Changed 8 years ago by rwall

A simple example of usage.

Changed 8 years ago by rwall

A updated diff requires reactor to be passed as an argument and without redefining backlog default value; plus an SSL option, thanks to exarkun and tv for ideas.

1

follow-up: ↓ 2   Changed 8 years ago by rwall

I've updated my original diff to accept the reactor as an argument and to not override the default backlog argument defined in reactor.listen*

exarkun - you suggested that backlog should be passed as an optional argument to IAddress.init, but I can't see what's wrong with having it as an argument of "listen"

Also, are you sure it wouldn't be better to have connect and listen in a separate class like in dreid's endpoint branch. Just without the adaption, CallableFactory, or WrappingProtocol stuff. Perhaps instead have eg IPv4Address.buildEndpoint(sslContextFactory).connect()

Finally

2

in reply to: ↑ 1   Changed 8 years ago by dreid

  • cc dreid added

Replying to rwall:

I've updated my original diff to accept the reactor as an argument and to not override the default backlog argument defined in reactor.listen* exarkun - you suggested that backlog should be passed as an optional argument to IAddress.init, but I can't see what's wrong with having it as an argument of "listen" Also, are you sure it wouldn't be better to have connect and listen in a separate class like in dreid's endpoint branch. Just without the adaption, CallableFactory, or WrappingProtocol stuff. Perhaps instead have eg IPv4Address.buildEndpoint(sslContextFactory).connect() Finally

A large reason why it was ever in a seperate class was my attempt to get rid of Factories as an interface and instead shift them to where I feel they belong, which is as a pattern. I've found that more often than not it is unnecessary to have a factory when working with clients, the endpoints branch also removed them from the server side purely for symetry. One thing you definitely need to do is make the tests clean up after themselves though. Having connect and listen on the IAddress is still really useful.

Regarding backlog: the beauty of endpoints is that every IAddress implementation can provide the exact same interface .listen(factory) .connect(factory) any other arguments given to the respective reactor calls should be instance variables on the object. backlog is one of these, as would be the sslContextFactory. (which is why there is essentially an IClientEndpoint and IServerEndpoint implementation for every reactor.listen and reactor.connect pair, and SSL is distinct from TCP.) Another reason the endpoints don't map directly to an IAddress is demonstrated by UDP vs TCP vs SSL. They all expect the same IAddress implementation, but their connect and listen methods require different configuration such as the sslContextFactory. So i think the most useful course of action would be to keep the IClientEndpoint and IServerEndpoint interfaces, but remove the attempt at getting rid of Factories.

3

  Changed 4 years ago by exarkun

  • status changed from new to closed
  • resolution set to duplicate

I think that this is more than related to #1442, it's actually a duplicate of #1442. The point of each ticket is the same: create APIs for clients and servers which are orthogonal to the actual transport being used.

4

  Changed 3 years ago by <automation>

  • owner exarkun deleted
Note: See TracTickets for help on using tickets.