Re: [asio-users] asio and SCTP

[Yuri T. <yti...@gm...>]

Hi everyone,

I think you're trying to make different approaches work together: Generic
Programming (which asio is built on) and Object Oriented Programming (when
using runtime polymorphism like newSock.reset(new tcp::socket(*m_ioService,
tcp::v6()));).

In ASIO there are no classes, there are concepts and algorithms. So that
asio::ip::tcp::socket models different concepts: socket, stream socket, io
object, etc. And if you try to implement SCTP support, your SCTP socket
should also implement some concepts like AsyncReadStream or
DatagramSocketService (and don't have to be derived from basic_socket or so
- it just a matter of implementation details). Having this you can use whole
range of asio's algorithms which work with required types (like
async_read_until or similar). Also your primitives can provide additional
control mechanisms either through existing concepts like
SettableSocketOption or have something completely different which applicable
only to SCTP.

This is very good, but in real world applications, where you need dynamic
behavior this doesn't work at all or a madness (like making *whole* your
application template-based and writing somewhere in main() if (use_ipv6())
app<asio::ip::tcp::v6>::run())).

So anyways you can't escape switching from GP back to OOP somewhere. And if
you're using asio as a tool, not as a framework, you can write your own
abstraction layer above socket operations which suits your needs. In my
application, I have to receive RTSP stream, which can be sent either by UDP
or tunneled through TCP. But anyways it has a packet on output. So I've
separated these cases, each receives and handles data separately, but the
outer interface is single and accepts a callback like boost::function.

I suggest you to try similar thing: make an interfaces and abstractions
where necessary which will hide whole transport details. But you should
concentrate not on technical things (like this is TCP and this is SCTP) but
rather on functional decomposition (like this routine provides data and that
one is responsible for processing).

The GP approach is very inconvenient sometimes, and very controversial. But
still you can easily write OO wrappers around ASIO's templates which suit
best your app's needs. If ASIO were based on virtual classes, we'd have a
completely different set of issues related with inheritance, virtual
functions and virtual inheritance.

Sorry for being a bit off-topic,
Yuri

P.S. this post was greatly inspired by recent posts from cpp-netlib
developer (which is based on ASIO and is candidate to boost):
http://cplusplus-soup.com/2010/11/22/life-after-oop/
http://cplusplus-soup.com/2010/11/25/generic-programming-in-your-domain/

On Thu, Dec 2, 2010 at 12:52 AM, Lothar May <lot...@go...>wrote:

> Am 01.12.2010 21:01, schrieb Marsh Ray:
> > On 12/01/2010 01:22 PM, Lothar May wrote:
> >> I agree, but that was not my point. My point is that SCTP can be used
> >> just as TCP (or as UDP), and for example reliable UDP can also be used
> >> just as UDP, but the asio library does not support such an approach.
> >>
> >> If I decide to enable SCTP support for an existing application, I need
> >> to also support TCP (or whatever was used before), to provide backwards
> >> compatibility. I can provide additional features to SCTP users, but that
> >> is beside the point.
> >
> > It seems relevant to me.
>
> Yes, I did not phrase that correct. It is relevant, but you can always
> provide additional methods which are not supported by all protocols
> (some return an error value "unsupported", and that is that).
>
> >> Currently, using asio it takes lots of efforts to switch an application
> >> from using "TCP" to using "TCP or SCTP", while it can be used just the
> >> same (skipping the new features). This is bad, in my opinion.
> >
> > Why would anyone change an application from TCP to SCTP if not to use
> > something new provided by SCTP?
>
> There are builtin features which are used automatically. This is
> slightly off topic, but: The SCTP handshake is way more reliable and
> secure, SCTP has a builtin heartbeat feature (in my opinion very
> important, if you ever had pending TCP connections which take around 20
> minutes or more to realise they are gone), SCTP has better congestion
> control, a "real" checksum, ...
>
> >> I totally agree that SCTP has new features. But they are optional. The
> >> BSD socket interface can also be used just the same as TCP, skipping the
> >> new features. And this is the way to go to enable optional SCTP support
> >> for applications.
> >
> > If that were the case, you could implement SCTP with simply an option
> > flag on the existing ip::tcp classes.
>
> Yes, indeed I think that this is possible. But it conflicts with the
> namespace "tcp", and also in the same way it would be integrated in
> ip::udp, so this is kind of absurd.
>
> I think the approach as suggested by Illia Bobyr, using e.g.
> "ip::stream" and "ip::datagram" instead of classes "ip::tcp" and
> "ip::udp" to me sounds like the way to go.
>
> > But I suspect that either you're planning to do an incomplete
> > implementation of someone else's application protocol or you, in fact,
> > do expect something more from the SCTP connection. But what exactly? Are
> > you sure it doesn't need to expose a different interface?
>
> I think I need to expose additional methods and maybe options, but those
> could be unused for other protocols, see above.
>
> [...]
> > I'm sorry if it sounds like I'm giving you a hard time - I'm just trying
> > to ask the questions now to reduce the chance that interface design
> > decisions don't come back to bite us later.
>
> Please don't be sorry, I would like this issue to be thoroughly
> discussed. I may be completely on the wrong track and not realising it.
> So thanks for your feedback.
>
> Regards,
> Lothar
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> asio-users mailing list
> asi...@li...
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>