Re: [asio-users] asio and SCTP
Brought to you by:
chris_kohlhoff
From: Lothar M. <lot...@go...> - 2010-12-01 19:22:12
|
Hi, Am 01.12.2010 19:55, schrieb Marsh Ray: > On 12/01/2010 10:43 AM, Lothar May wrote: >> Am 23.11.2010 20:53, schrieb Lothar May: >> [...] >>> I don't see why a difference in OSI layer 3 is as easy as this: >>> >>> boost::shared_ptr<tcp::socket> newSock; >>> if (use_ipv6()) >>> newSock.reset(new tcp::socket(*m_ioService, tcp::v6())); >>> else >>> newSock.reset(new tcp::socket(*m_ioService, tcp::v4())); > > Ideally, it wouldn't even be that hard. :-) > >>> while a difference in OSI layer 4 leads to so much complexity, [...] > > Because the protocols have different capabilities and different interfaces. > > In your layer 3 IPv6 vs IPv4 example, those protocols were carefully > designed to need (almost) no application code changes. > > But UDP, TCP, and SCTP are all IETF protocols at the same layer. The > IETF wouldn't develop three different protocols if they all did exactly > the same thing, would they? 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. 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. > We just got lucky with UDP and TCP. Although they are opposites in > important ways (unreliable vs reliable, unordered vs ordered, message > oriented vs stream oriented), due to some as-yet-undiscovered symmetry > of the universe the API needed to support them is almost exactly the same. > > SCTP is not just streams, or messages. It can send multiple messages, > simultaneously, each in its own stream. So we can't get away with > overloading the same interface anymore. 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. >> Any more feedback on this? Does someone maybe know a C++0x "trick" to >> deal with this situation? Otherwise, the only possibility I see would be >> to create a fork of asio for SCTP support. > > Perhaps you could make a new 'asio::sctp::association' type for the > basic association between peers. Like tcp and udp, this would be derived > from an instantiation of the basic_socket template, but not derived from > basic_stream_socket or basic_datagram_socket. > > Operations on this association could be used to set up more conventional > "socket" like objects. The SCTP RFC refers to them as "streams", but I > think this type might be more appropriately derived from > basic_datagram_socket. > > An application using asio SCTP support might be obligated to keep an > outstanding read operation going on the sctp::association and for every > active sctp stream at the same time. New stream connections arrive on > the sctp::association object (like new tcp connections) and new messages > arrive on the sctp::stream object. I'm afraid this is exactly the way I would not like to go, because it prevents the use of SCTP sockets just like TCP (or UDP) sockets. And in my opinion, this abstraction should not be in the application, it should be in the lib. Regards, Lothar |