[recon-devel] Flow::onReceiveSuccess(...) and Flow::onReceiveFailure(..)

[Jeremy Geras <jgeras@xxxxxxxxxxxxxxx>]

Hi,

 

We're looking at building native support for reflow "Flows" into our media stack, and there are a couple of design considerations I'd like to bring up:

 

1) How to handle error conditions?  Currently Flow::onReceiveFailure(..) just logs an error -- is this sufficient?

 

For example, what to do if you get ICMP unreachable when you send UDP to the other side?  We've found that there are enough badly implemented endpoints around that that it's actually worth our while to keep trying to send RTP to the other end (i.e. optimistically assume that it will be ready at *some* point a few fractions of a second later).  On Windows, this requires us to close down/reopen our UDP socket (MSDN states that sockets are invalidated when you get ICMP errors).

 

For this particular situation, this is our preferred way to handle this problem -- I'm not sure if it's a solution that should be built in or not.  However, it's one case where currently we would need to modify Flow.cxx if we wanted to implement it.

 

2) How to receive incoming RTP?  Currently the design assumes that you call Flow::receive(..) from another thread.

 

Since the data is going to end up in a jitter buffer anyways, would it be prudent to provide a callback/handler class that provides the opportunity for us to do whatever we need to do in the context of the thread that is calling Flow::onReceiveSuccess(..) (i.e. the thread that calls io_service::run())?  It seems like this might be a worthwhile optimization (eliminates a queue and a thread).

 

So for both 1) and 2), I think a new handler class, called by Flow in onReceiveSuccess(..) and onReceiveFailure(..), might be a reasonable solution.  Before I start experimenting too much with this approach, I thought I'd throw it out there for feedback -- any thoughts?

 

Thanks,
Jeremy