ccrtp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] IPv6 support in ccRTP - iqueue problems...


From: David Sugar
Subject: Re: [Ccrtp-devel] IPv6 support in ccRTP - iqueue problems...
Date: Sat, 07 Oct 2006 11:53:35 -0400
User-agent: Thunderbird 1.5.0.7 (X11/20060913)

While I can merge the receiver code for both ipv4 and ipv6 cleanly into a single outqueue class which can handle both without breaking anything, I do not think this is as easy to do in iqueue.h/incqueue between all the subclasses related to syncsource which also are address aware and the way it is interconnected currently. It may in fact be easier to have an entirely separate i4queue.h, inc4queue.cpp, members4.cpp, etc, with new xxxIPV6 versions of all those things, to handle inbound IPV6 packets...

I checked in my changes for ipv4/ipv6 outbound packet handling, which went very well, and thought I would wait for you to comment.

Federico Montesino Pouzols wrote:
The CCXX_IPV6 wrapped classes seem a practical and quick fix. I can't
think of a simpler way of fixing this problem. I agree it looks a bit
ugly, but it seems the best short term solution. We should think of
a tidier solution for the future :)

Maybe IP addresses should be handled in a different way in ccRTP, or
maybe a common base class for both IPv4 and IPv6 addresses could be
added to CommonC++.

On Thu, October 5, 2006 2:01 pm, David Sugar wrote:
When I look into the case of OutgoingDataQueue, I was thinking maybe in
that particular case, we can have a CCXX_IPV6 wrapped
OutgoingDataQueueIPV6 which inherits from the existing
OutgoingDataQueue.  It could re-implement just those methods that deal
with addresses with new methods that use the IPV6Host objects, cap the
v4 virtual with a dummy method, and offer a new v6 virtual of it's own.
  We could then feed OutgoingDataQueueIPV6 to the upper level template.
  That might be ugly, but it could work without breaking a lot of
existing code or writing all that much new code.  The same could
probably be done for the other two classes.

I would like to see some feedback on this before doing this :).





_______________________________________________
Ccrtp-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/ccrtp-devel

Attachment: dyfet.vcf
Description: Vcard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]