[Twisted-Python] Is there a nice way to write transport-agnostic protocols and servers/clients?

[Kevin Conway]

> There is no datagram endpoints API as yet, though (see #4471), only
stream endpoints.

I've read through the ticket. What I still don't understand is the
significance of this of this? Other than some irrelevant callbacks, what
prevents anyone from using the existing UDP endpoint? It's not clear from
this thread why the specific transport abstraction is critically
important to the data protocol.

If you are building a Protocol then you use the 'dataReceived' callback to
parse the data. Can someone elaborate on why it matters if the bytes get
here via a datagram or TCP stream?

> But it doesn't provide a uniform abstraction over both stream-based and
datagram-based transports.

Again, why does this matter? If you run a service with multiple listening
transports, why does it matter which one is active? What differs in the way
you interpret the bytes received?

On Wed, Aug 16, 2017 at 9:03 PM Kevin Conway <kevinjacobconway at gmail.com>
wrote:

> > There is no datagram endpoints API as yet, though (see #4471), only
> stream endpoints.
>
> I'm not sure I understand the distinction. Endpoints supports UDP which is
> a datagram based transport. From a Protocol perspective, you only care
> about which bytes are received. If you have a framing concept I'm your data
> format then it should be handled there.
>
> What am I not understanding about this particular use case?
>
> On Wed, Aug 16, 2017, 16:25 Jean-Paul Calderone <exarkun at twistedmatrix.com>
> wrote:
>
>> On Wed, Aug 16, 2017 at 9:59 AM, Tristan Seligmann <
>> mithrandi at mithrandi.net> wrote:
>>
>>> On Wed, 16 Aug 2017 at 15:28 Kevin Conway <kevinjacobconway at gmail.com>
>>> wrote:
>>>
>>>> Maybe I misunderstand the issue, but I believe the Endpoints API solves
>>>> for this.
>>>> https://twistedmatrix.com/documents/16.4.1/core/howto/endpoints.html
>>>>
>>>> This abstracts the transport and allows you to focus on only
>>>> interpreting the bytes transmitted over that transport by defining a
>>>> Protocol and a Factory that plug into strports. This should allow you to
>>>> have the business logic defined in only one location while
>>>> listening/requesting over different transports.
>>>>
>>> There is no datagram endpoints API as yet, though (see #4471), only
>>> stream endpoints.
>>>
>>>
>> Also, when there are datagram endpoints, they won't be compatible with
>> stream endpoints.  Endpoints don't abstract the transport, they abstract
>> *creating* the transport.
>>
>> Twisted provides a uniform abstraction over stream-based transports like
>> TCP and gives you *ITransport* to implement an *IProtocol* against.  It
>> also provides a uniform abstraction over datagram-based transports like UDP
>> and gives you *IUDPTransport* (oops; should have been
>> *IDatagramTransport* and some other things about it should probably be
>> changed too) to implement a *DatagramProtocol* (oops; no interface for
>> this one, just subclass: see, this should change) against.  But it doesn't
>> provide a uniform abstraction over both stream-based and datagram-based
>> transports.
>>
>> Implementing such a thing may be possible and even a good idea but no one
>> has yet done it for Twisted (as far as I know).
>>
>> Jean-Paul
>>
>> _______________________________________________
>> Twisted-Python mailing list
>> Twisted-Python at twistedmatrix.com
>> https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20170817/5e3a6da4/attachment-0002.html>