> 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 <kevinjacobcon...@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 <exar...@twistedmatrix.com> > wrote: > >> On Wed, Aug 16, 2017 at 9:59 AM, Tristan Seligmann < >> mithra...@mithrandi.net> wrote: >> >>> On Wed, 16 Aug 2017 at 15:28 Kevin Conway <kevinjacobcon...@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@twistedmatrix.com >> https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python >> >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python