Yea, I'd agree too. VIC and RAT use UDP, which is by design
connectionless. You either get packets or you don't. VIC and RAT will
hang around forever waiting for something. VIC holds on to 'dead'
streams for up to a minute or two before they 'drop off'. If the source
comes back with the same SSRC then it just picks up where it left off,
but if they came back with a different SSRC (i.e. THEY restarted their
VIC/RAT) then they'll pop up in different windows. RAT times out its
entries quicker than VIC does AFAICS. The Venue Client is indeed a TCP
based connection so that's the only 'connection' in place (actually 2
TCP connections).
Derek
John Hodrien wrote:
> On Mon, 31 Oct 2005, John Langkals wrote:
>
>> Ultimately this is difficult to debug without giving you more concrete
>> data
>> but from your experiences, what could have been going on? I would have
>> expected to have been disconnected from the venue and require
>> reconnecting
>> to the room.
>
>
> I'd agree that this sounds like it could be multicast problems. The
> connection to the AG VenueServer is going to be unicast isn't it, so that
> would survive. vic and rat are both designed to cope with 'losing
> connection' and picking back up again without intervention, so I think that
> fits.
>
> jh
>
--
Derek Piper - dcpi...@indiana.edu - (812) 856 0111
IRI 323, School of Informatics
Indiana University, Bloomington, Indiana
