HTTP je protokol koji obitava samo iznad TCP layera, i prema tome za početak bi bilo dobro da počneš da portuješ tu aplikaciju ka TCP načinu prenosa.
Time postoji šansa da se izgubi mnogo na perfomansama, jer onda bi za svaki paket trebala da se vrši provera, što kod UDP načina prenosa ne treba.


Razmisli još jednom da li to zaista želiš.




*

Radi se o HTTP streaming-u. Znaci nista TCP.
Trenutno aplikacija prenosi live (audio i video) sadrzaj preko UDP, i to radi dovoljno brzo. Sad bi to trebalo prebaciti na HTTP (nista TCP zbog firewall-a). Zanima me da li HTTP streaming radi samo sa fajlovima (znaci kad salje neki sadrzaj on salje deo nekog fajla) ili radi i sa live sadrzajima i kako onda u tom slucaju radi, da li ima nekog preteranog zastoja ?!

______________
Keep on going ...

Ne postoji nesto sto ti nazivas HTTP streaming-om.. HTTP protokol je samo jedan od protokola iznad TCP layera (kao sto vec Bojan rece), i sam HTTP protokol ne omogucava nikakav streaming. Znas li ti uopste sta je HTTP protokol i za sta sluzi?


Btw, zasto to uopste zelis (kako si se izrazio) "prebaciti na HTTP"? Sta uopste zelis da kazes, odnosno sta uopste hoces? Opisi problem malo detaljnije.

Sto se tice HTTP streaming-a i odredjenih osoba koje u to neveruju neka u pretrazivacu otkucaju "HTTP streaming" pa da vide sta ce da dobiju kao rezultat.

Dakle, trenutno prenos audio i video zapisa preko UDP ide Ok, ali pojedini firewall-ovi kao sto je poznato ne dozvoljavaju prenos preko odredjenih protokola koristeci odredjene protokole. Iz tog razloga se uvodi prenos preko HTTP-a koji svaki firewall dopusta, samo nisam siguran koliki bi zastoj u prenosu live sadrzaja u tom slucaju bio !!!

_____________________
Keep on going ....

Moguće je prenositi video HTTP-om ali mu baš ne stoji da se zove "stream", već kao i sav ostali sadržaj koji ide HTTP-om, prvo se dovuče pa se konzumira, bilo to u segmentima ili odjednom. To je poznato kao "narodni" metod za audio/video, jer ti ne treba nikakav medija server već običan web server. U principu to nije nikakvo rešenje, prvo jer je upotrebljivo samo na manjim fajlovima, saobraćaj nije raspoređen klijentima kako treba, troši mnogo više resursa mreže nego pravi streaming, itd.

Mihailo u kontekstu toga da se nadovezem sto me zanima, u slucaju sto ti kazes 'narodni' metod za audio/video -> u tom slucaju radi se sa fajlovima, da li je moguce slati znaci audio/video preko HTTP-a a da to nije rad sa fajlovima ?!

_______________
Keep on going ...

U tome je poenta - HTTP streaming ne postoji, nego je neko mnogo pametan nazvao tako običan web server koji služi audio/video fajlove.

Nego sa cime? Covece, trebalo bi da se informises o osnovama HTTP protokola, kako se ovakve tvoje budalaste izjave ne bi ponavljale..

HTTP protokol sam po sebi ne moze (kao sto sam vec rekao) da radi streaming.. Vec je to nekakav kvazi-streaming (ili se bar pokusava nazvati streaming) koji je DALEKO od onoga sto tebi treba.

Slanje video/audio fajlova preko HTTP protokola radi kao i slanje svih drugih fajlova, npr. HTML fajlova. Konektujes se na HTTP server, zatrazis sta ti treba i on ti to posalje. Tek posto ti on to posalje mozes to i da vidis (iskoristis).

Sad, kako si ti mislio da tu "uglavis" streaming, meni nije jasno..

Nesto najblize streaming-u je mod_mp3 za Apache.. Ali, opet to nema neke preterane veze sa samim HTTP protokolom.

Poz, alex.

HTTP streaming radi sledece: umesto *.html fajla kao zahtev salje se zahtev za nekim fajlom koji predstavlja video sadrzaj i koji se na klijentskoj strani dekompresuje i onda poziva odgovarajuci player. Prosto ko pasulj ...
Samo sto taj rad sa fajlovima dosta usporava rad .... znaci trenutno se salju paketi kako se reprodokuju na strani koja emituje video sadrzaj, takodje na klijentskoj strani se oni primaju bez cekanja. Ova stvar sa upisom u fajl, pa onda citanje pa slanje klijentu dosta usporava ....


________________
Keep on going ...

Hej, Hoj

sergio pokusava da pointuje na nekakav sekvencijalni stream, ako se tako nesto uopste moze nazvati stream. Jer, tada bi se video/audio zapis slao u delovima promenljive velicine. Zaista jos jednom podvlacim da li ti je zaista potrebna TCP komunikacija ? Time opterecujes i server, i klijenta, posebno ako radis nesto "golemo", i za opste narodne mase.

A ovo za firewall je notorna glupost. Svaki firewall propusta ono sto mu se DOPUSTI da radi, a ne ono sta on HOCE.

Ajde pojasni malo bolje ako nije problem.]

pozdrav

Live sadrzaj bi se znaci slao nakon kompresije.
Ne govorim o TCP komunikaciji, zanima me samo HTTP port 80 koji vecina firewall-ova dopusta.
Znaci preko HTTP porta 80 slanje odgovarajuceg sadrzaja.

_______________
Keep on going ...

Onda tebi ne treba http streaming niti nista slicno tome (ionako ne postoji)

Jednostavno portuj aplikaciju da radi preko tcp protokola i da koristi port 80 i proci ces kroz firewall !!!


Kolka tema zbog notorne gluposti al ja nisam hteo posle Bojana da odgovaram jer sam mislio da je on rekao sve sto treba.

PORTUJ APLIKACIJU NA TCP I NEK RADI NA PORTU 80 !!!


PS: to sto se port 80 navise koristi za http to nema nikakve veze, ja ako ocu mogu da dignem ssh na portu 80 ili smtp ili pop3 to je krajnje nebitno port je port i moze da sluzi za sta oces dok god nije zauzet.

Hajde sad da vidimo ko koliko zna sto se tice firewall-a !
Da li ce TCP paket proci preko firewall-a koji dozvoljava samo HTTP saobracaj i to preko port-a 80 ?!

Ovo pitanje je u kontekstu prethodne price ...

_______________
Keep on going ...

Hey ho,
ti malko pricas napamet, no ajde ...

Znaci, firewall pravila se kreiraju na osnovu:
o Porta ( numericka vrednost 1-65536 )
o Protokola ( tcp,udp,icmp )
o IP adrese

Mozda nisam bio jasan. Dakle, firewall dopusta HTTP preko porta 80 !

Sta u tom slucaju raditi ?!


_______________
Keep on going ....

Vrlo bitna stavka - gde se taj tvoj firewall nalazi? Ispred servera (ka Internetu) ili ispred klijenta?

U prvom slucaju, on bi trebalo da bude konfigurisan da samo prima konekcije na tcp port 80 i propusta ih do web servera.

U drugom slucaju, firewall je konfigurisan da samo propusta konekcije napolje (ka internetu) na port 80, sto znaci da je klijentima samo omoguceno da posecuju web sajtove i nista vise.

Sad, koja je situacija u pitanju?

U prvoj situaciji, web server moze da servira i video/audio zapise, ali samo kao obicne fajlove (odnosno HTTP GET).

Posto ocigledno ne poznajes materiju dovoljno da bi je i objasnio kako treba, izvoli pokusaj bar da se lepo izrazis.

Jedino da probas da promenis taj tvoj UDP streaming protokol tako da koristi TCP pakete umesto UDP - i da probas da to propustis preko porta 80 u tvojoj kompanijskoj mrezi - ovo moze, ali NE MORA da radi (sve zavisi kako je setovan firewall)

Uopste uzevsi, za streaming postoji RTP protokol koji je baziran na UDP paketima. Streamovati nesto preko TCP-a je kvazi-resenje, ali ponekad neophodno.

Mozda je lakse da popricas sa administratorom i da ti dozvoli UDP (RTP) saobracaj na odredjenom portu.

Prvo ide klijent, pa firewall pa onda internet i na drugom kraju negde je server na koji trebaju da se konektuju klijenti.
Drugo, ne radi se o mom licnom problemu nego se radi o sutuaciji kada je korisnicima omoguceno samo http (znaci posecuju sajtove nista vise) !
Jos jednom: znaci firewall dopusta samo http saobracaj preko porta 80.


______________
Keep on going ...

Pa pazi, ako su ti ciljne grupe korisnici koji koriste HTTP proxy server, onda ti opet ne odgovara ni da portujes taj live streaming na TCP, jer opet proxy ce da razume samo HTTP1.0 ili HTTP1.1 protokol. Jedino da se proxy prosiri sa nekim dodatnim extenzijama za proksiranje udp saobracaja, ili nesto slicno, ali to je samo subjektivno resenje.

Zaista je zalosno sto neki ljudi jos uvek Internet vide samo kroz rupicu proxy servera l;(

Niko nije rekao da se koristi proxy. Mozda je samo masq sa firewall-om koji dozvoljava prolaz kroz tcp:80. Ili mozda klasicno rutiranje sa istim firewall-om.
Sve u svemu to je ona druga solucija sto je alex naveo tako da slobodno portuj aplikaciju na tcp i na port 80 i radice ali samo ako ne idete na net preko proxy-ja. Pitaj admina dal idete preko proxy-ja ili direktno.

PS: firewall-a ne zanima dal je to http ftp smtp pop3 pop2 imap4 imap3 ili neki tamo peti sunrpc protokol. njega samo zanima tip prenosa podataka udp tcp icmp port preko koga se odvija komunikacija i ip adrese izmedju kojih se odvija konverzacija.
Tako da sto se firewall-a tice ako tebi program cilja na port 80 preko tcp-a.

Ajde da vidimo ko koliko zna oko protokola prvo, pa da onda unapredjujemo pricu na firewall. Koliko ja znam, HTTP je protokol aplikativnog nivoa TCP/IP stacka, a TCP i UDP su protokoli transportnog nivoa (iliti layer-a) Tj, HTTP je protokol koji "radi" po TCP portu 80. koliko ja znam ne postoji UDP port za HTTP. Drugo, firewall pusta, kao sto je neko vec rekao, ono sto mu ti kazes da pusta. Takodje, "HTTP streaming" ne postoji. Trece, postoji nesto sto se zove OSI referencni model, sto ljudi koji su odgovarali na celu ovu temu ocigledno znaju, te, sergio, potrudi se da ga i ti pregledas.

Protokol koji omogucava prenos A/V zapisa, a koji egzistira u okviru HTTP-a je RTSP (Real Time Streaming Protocol ). Vise informacija na web adresi www.rtsp.org

za sergio-a

Kada neki racunar hoce da ostvari komunikaciju sa drugim racunarom desava se sledece ( ovde pod komunikacijom ne podrazumevam pingovanje ili neke slicne svari vec konekciju na aplikativnom nivou ) :

Aplikacija sa racunara1 poziva aplikaciju na racunaru2. Da bi taj poziv otisao sa racunara1 na racunar2 mora do tamo nesto da ga nosi. To rade protokoli i to ne bilo koji . Tacno se zna njihov redosled. Aplikaciju ne moze da nosi neki protokol iz transportnog sloja kao sto je npr. TCP ili UDP ili sa internet sloja kao sto je ICMP ili ARP nego samo protokol koji radi na aplikativnom nivou. I cak ni ovde na aplikativnom nivou ne moze bilo koji aplikativni protokol da nosi bilo koju aplikaciju.

Znaci odredjena aplikacija sa racunara1 krece da se da se obraca odredjenom racunaru2 tj. odredjenoj aplikaciji na tom racunaru.Nju do drugog racunara nosi tacno odredjeni protokol na aplikativnom nivou koji je predodredjen za tu aplikaciju.
Dalje, nije ni to dovoljno, jer ne moze protokol na aplikativnom novou sa racunara1 da komunicira sa istim tim protokolom na racunaru2 sam od sebe. Nego i njega neko mora da nosi. Tako da sada aplikaciju koju nosi aplikacioni protokol sada sve njih zajedno nosi novi protokol na nizem nivou tj. na transportnom layer-u.

I tek tada se ostvaruje komunikacija. Odlazi se do drugog racunara i dolazi kod njega na transportni layer-u. I sada idemo obrnutim redosledom. Kako smo se tamo od aplikacije pa preko protokola na aplikativnom nivou spustali nadole tako ovde na racunaru2 mi se od najnizeg penjemo na gore i dolazimo do aplikacije.

Racunari1 i 2 su ostvarili komunikaciju.

Naravno ova prica vazi za i za tvoj slucaj. Ako imas neku aplikaciju koja radi na nekom racunaru i koja kontaktira neki Server radi razmene real-time videa, voice stream-a, data stream-a ili kombinacije ovih elemenata mora da postoji protokol preko koga ce sve to da funkcionise. Ali to je protokol na aplikativnom nivou a ne protokol na transportnom layer-u. Znaci tvoje podatke sigurno ne nosi UDP nego opet ponavljam neki aplikativni protokol koji sluzi tacno za tu aplikaciju i koga ona poziva kada krece konekcija a taj protokol nosi UDP na transpornom sloju.

Znaci nije tebi bitan UDP. Tebi je bitan aplikativni protokol. A UDP i TCP su low-level protokoli koji ce u svakom slucaju raditi ispod na Internetu. Jer ta dva protokola nose skoro sve aplikativne protokole na Internetu ( osim naprimer kada pravimo VPN pa koristimo PPTP protokol da ostvarimo tunnel konekciju-on ne koristi ni UDP ni TCP ).

Iz ovoga sledi da nemozes da menjas UDP sa HTTP-om jer je HTTP je aplikacioni protokol, oni su sa dva totalno razlicita layer-a.

Dalje nemozes ni da menjas ni da su ti protokli na istim layer-ima, naprimer da su oba na aplikativnom nivou. Jer tvoja aplikacija koristi tacno odredjeni protokol i da bi koristio drugi protokol na aplikativnom nivou aplikacija mora da ga prepozna a ne da ti odlucis da menjas tek tako.

Dalje ako mozes da koristis HTTP protokol ti znaci koristis neki browser, znaci tvoja aplikacija je browser i ona moze da gadja samo Web Server to jest IIS service na njemu koji je po defaultu ostavio port 80 koji ceka da se uspostavi konekcija.


Protokoli koji se koriste za to sto ti trazis su npr. PNM-RealNetwork protocol, RTSP, MMS-Windows media protocol ....

Ali opet ti kazem odredjena aplikacija vuce odredjeni protokol.

Sto se tice Firewall-a, svaki Firewall propusta samo ono sto onaj koji ga odrzava odredi ( kao sto je neko vec ranije rekao ). Tako da on uopste nemora da propusta HTTP ako nije tako setovan. Radi se o tome da su skoro svi Firewall-i u namesteni da pustaju HTTP da bi moglo da se ide na Web site-ove.

Posto si napisao da treba da prodjes kroz Firewall da bi otisao na taj server na Internetu treba da znas tacno koji protokol koristi ta aplikacija i da znas na kom portu radi ta apikacija. Kada imas te informacije pravis rule
koji propusta kroz Firewall bas ono sto ti hoces i ti odlazis na zeljeni Server.
U celoj ovoj prici najbitniji je port.
Jer sa tim portom tvoja aplikacija gadja Server na Internetu. A taj Server bas na tom istom portu ceka.

Znaci ono sto si napisao da Firewall propusta samo HTTP preko porta 80, nepropusta on to tako. Tvoj Web browser gadja Server i to Web server
na Internetu. Zahtev sa tvog racunara ili bilo kog klijentskog racunara koji se nalazi iza Firewall-a dolazi do tog Firewall-a. I sada on propusta HTTP zahtev ali ne na portu 80. On otvara bilo koji port na kartici i to svaki put drugacije iz nekog opsega portova npr. 3012 ( dinamicki portovi ).
Ali zato kada dodje na odredisni Server on gadja PORT 80 , a ovaj ga upravo na tom portu ceka.

Mirko