Video-ström utanför LAN med JMF

Jag använder alltså JMF för att hämta en bildström från min webbkamera och försöker skicka den vidare ut på Internet. Jag är lite osäker på hur RTP och videoströmmar fungerar. Säger den som skickar en ström vilket IP som har tillträde att lyssna och sedan ansluter den som vill lyssna till Server-IP? Vilka brandväggsproblem kan uppstå? Jag har enbart provat att skicka/ta emot där det finns en brandvägg i ena änden. Har provat både där brandväggen varit hos den som sänder och den som tar emot.
När jag påstår att det inte finns någon brandvägg i ena änden så menar jag egentligen bara att jag har öppnat portarna 22224-5.

Testerna fungerar bra inom LAN men såfort jag försöker genom WAN så går det inte längre. Den som ska ta emot kastar ut meddelanden att den fortfarande väntar på en RTP-ström.

Följande program använder jag:
För att skicka: VideoTransmit
För att ta emot: AVReceive

Jätterörigt? Hoppas någon kan förklara hur man ska gå till väga för att skicka utanför LAN och således vilket fel jag gör.

Som du säkert redan har förstått är det en ren djungel det här med att sända data över nätverk. Det går därför inte att svara på dina frågor utan att veta lite mer vad det är du ska göra.
Ska du sända en videoström till en person? Flera personer? Ska du använda dig av unicast eller multicast? Körs RTP över UDP?

Nu rörde jag säkert bara till det ännu mer, men vi måste veta mer innan det går att svara på dina frågor. Så exakt vad vill du göra?

Vad jag exakt vill göra:
En klient (applet) ansluter till en server (samma som appletten ligger på) och säger "Hej, jag vill se videoströmmen". Någon form av autentisering görs sen ska servern börja skicka strömmen till klienten. (det är bara detta lilla sista steg som jag försöker klara ut för tillfället).

Unicast eller multicast? Den ska endast sända till en person åt gången iaf.
På frågan om RTP körs över UDP så vet jag inte, men förhoppningsvis, ja. Hur anger jag det, säger inte koden jag länkade till vilken protokoll som används? Hur som helst så föredrar jag helt klart UDP eller snarare det är ett krav.

Gein skrev:

På frågan om RTP körs över UDP så vet jag inte, men förhoppningsvis, ja.

Kollade lite på detta och såg att den kör över UDP. All trafik går från en hög port hos servern till den port på klienten som du får välja själv.

Gein skrev:

Vilka brandväggsproblem kan uppstå?

Eftersom det är servern som startar anslutningen till en viss port på klienten så måste brandväggen som skyddar klienten låta trafik till porten du valt att använda passera. Om klienten sitter bakom en NAT-brandvägg så måste brandväggen skicka trafiken på porten vidare till samma port på klienten.

Denna lösning med UDP är alltså inte speciellt bra ur användarvänlighetssynpunkt. Bättre skulle då vara att köra över TCP eftersom man lättare kan ta sig genom brandväggen, men då tappar man ju samtidigt fördelarna med UDP.
Är det bara en eller ett par klienter som ska få tillgång till din webbkamera så kan du ju konfigurera dom till att fungera, men är det tänkt för allmänheten kommer det nog inte att gå så bra tyvärr.

Tack för svaret. Det hela löste sig, som du säger, när vi öppnade portar in mot klienten. I vårat fall kommer det bara röra sig om fasta klienter som ska komma åt servern så vi kan nog konfigurera oss runt problemet.

Dessutom ska denna ström gå över atlanten, till/från USA. Tappar man inte rätt mycket om man då ska köra TCP? Jag pratar främst om tidsförskjutning men även i kvalite eftersom man inte kommer upp i samma hastighet.
Om inte, hur går man tillväga för att sköta streaming via TCP istället? Hur gör man det på ett sätt som gör att man inte får brandväggsproblem?

Härligt att det löste sig.

Den stora skillnaden mellan UDP och TCP är att UDP bara matar iväg datapaket till mot ett visst ip utan att kolla om paken kommer fram medans TCP håller koll på anslutningen och ser till att varje paket når fram och att dom gör det i rätt ordning. Skulle ett paket på vägen tex. slängas bort av en trött router så skulle den datan vara förlorad om du kör på UDP, medans om du körde på TCP så skulle paketet skickats om tills det nådde slutstationen.

Så ska man köra video över atlanten är det nog att rekommendera att köra UDP, även om det betyder att mycket data kan gå förlorad. Hellre lite sämre bildkvalite än att bilden "laggar" ut totalt som det kan bli med TCP.

Ska inte säja för mycket nu, för jag är inte säker, men jag tror att Skype kör tal över TCP, och det fungerar iaf för mig mycket dåligt över atlanten. Det bildas ofta en stor tidsförskjutning och tillslut dör anslutningen.

Anyway.. Tanken med att köra TCP istället för UDP när det gäller att ta sig genom brandväggen är att om du kör TCP så skapas en anslutning mellan server och klient.
Om klienten då skapar en anslutning till en port på servern som lyssnar efter anslutningar så kan servern skicka tillbaka data i samma anslutning. Moderna brandväggar känner nämligen av att klienten skapat en anslutning utåt, och tillåter därför servern att skicka data tillbaks till den porten på klienten som kontaktade servern.
Inga portar behövs därför öppnas hos klienterna, bara en port på servern.

Vart lite halvtaskig förklaring, så du får gäna ställa följdfrågor om det är nått som är oklart.

Den största anledningen till att man använder UDP för att streama är att TCP har något som kallas slow start (http://www.faqs.org/rfcs/rfc2001.html) och exponential back off. TCP börjar med en låg hastighet och ökar sedan tills ett paket förloras. Då sänks hastigheten drastiskt och ökas sedan sakta igen. Med UDP får man full hastighet från början. Är det viktigt att alla paket kommer fram kan man ganska lätt lägga till sekvensnummer i sina paket.

Dom stora skillnaderna mellan TCP och UDP förstår jag.

juventus1 skrev:

Den största anledningen till att man använder UDP för att streama är att TCP har något som kallas slow start (http://www.faqs.org/rfcs/rfc2001.html) och exponential back off. TCP börjar med en låg hastighet och ökar sedan tills ett paket förloras. Då sänks hastigheten drastiskt och ökas sedan sakta igen.

Det där kommer jag såväl ihåg från DataKomm-kursen nu när du säger det.

Det är inte speciellt viktigt att ALLA paket kommer fram. Huvudsaken är att man ser och förstår en videoström (ju tydligare desto bättre).
Problemet är som sagt en brandvägg i USA. Vi ska försöka få ett par portar öppna i brandväggen åt oss så att strömmen kan gå igenom men i värsta fall är detta inte möjligt. Och om jag förstår det så är den enda lösningen isåfall TCP? Det går inte köra UDP och komma runt brandväggen samtidigt, korrekt?

juventus1, intressant läsning, men hur mycket påverkas en TCP-anslutning av dessa algoritmer i praktiken?

Vid ett ovetenskapligt test genom att tanka en stor fil (Över 200 MB) från ett par olika ftp-servrar i USA så kunde jag bara se hastighetessänkningar på max 5%.
Sen tog det inte mer än någon sekund innan hastigheten kommit upp till max.
Använde mig av wget för att tanka ner filen, och vad jag vet ska dess hastighetsmätare spegla hur snabbt det går "just då" och inte visa någon halvtaskig medelhastighet som vissa andra program.

Gein, nej det går inte att komma runt brandväggen på något sätt med UDP om ni inte öppnar en port.

Det är inte speciellt viktigt att ALLA paket kommer fram.

Exakt. Ofta innehåller varje paket lite extra information som gör att man kan återskapa åtminstone delar av ett saknat paket. Alltså en typ av interpolering.

juventus1, intressant läsning, men hur mycket påverkas en TCP-anslutning av dessa algoritmer i praktiken?

Vet inte faktiskt inte... Det är väldigt svårt att säga. Om det är lite trafik i nätet så tror jag inte att det blir någon enorm skillnad på prestanda. TCP använder också (numera) fast-retransmit som innebär att man kan upptäcka att ett paket försvunnit ganska tidigt och då snabbt skicka om det. Sedan beror det också på hur stora fönster som används. Används stora fönster kan en bekräftelse gälla många paket. Det ger bra prestanda så länge det är lite förluster. Tappar man ett paket måste ett helt gäng paket skickas om. Men i princip alla protokoll för att streama använder ju UDP så jag antar att det i praktiken är en ganska stor skillnad. Problemet med mycket UDP trafik är att det protokollet struntar i andra strömmar. TCP sänker ju hastigheten när ett paket har förlorats och antar att paketet försvann pga congestion (ex. en buffer på en router var överfull). Det gör TCP-strömmer samsas om och delar på den tillgängliga bandbredden. UDP bryr sig inte utan fortsätter att sända i samma takt. Det gör att många paketet från den strömmen försvinner och att den strömmen förstår för en massa andra strömmar också.

Det bästa svaret jag kan ge är: det beror på konfiguration och trafikmängden i nätet. Men sök lite, finns mycket att läsa om detta och någon borde ha gjort lite mätningar.