Stream Server & Multicast support

 ( gabor2 | 2015. november 17., kedd - 12:07 )

Sziasztok !

Munkahelyemen egy stream server szeretnenk uzembehelyezni
100000+ nagyobb user szammal. Nem multimedia hanem sajat adatok.

Milyen szervert vagy technologiat tudnatok ajanlatni ami
tamogatja a multicast-ot?

https://en.wikipedia.org/wiki/Multicast

Sok user van aki ugyanazt a stream-et szeretne megkapni
es szeretnenk optimalizalni valahogy a szervert.

Gabor

Update:
PAAS (Cloudban). Nekünk csak a technológiát kell meghatározni.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"100000+ nagyobb user szammal."
Ez hogy jott ki?

Azt mondta a főnököm, hogy ennyi lesz.

"100000+ nagyobb user szammal. Nem multimedia hanem sajat adatok."
Ez mit takar gyakorlatilag? Mi lenne a konkrét cél?
(rejtett sub)

Bocs, részletegbe nem akarok belemenni.
Internetten lévő device-ok status-at kell
streamelni (json) a usereknek.

Subscribe. 100k nem kevés, kíváncsi vagyok, mi lesz belőle.

+1

ha dvb-* forrasbol megy a video stream akkor mumudvb tud multicaston szorni az adast.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem vagyok nagyon jartas ebben a temaben. Tudnal valami linket adni errol.

Koszi!

A videóformátum nem derült ki a topicnyitásnál, de egyébként jó szívvel tudom javasolni a Wowza-t.

A fizikai infrastruktúra multicast-képes? Milyen infrastruktúra az, amin 100k user lakik?

A cloud megoldással az lesz a baj, hogy a cloud szolgáltató és a helyi júzerek között nem biztos, hogy végig fogod tudni tolni a multicastot infrastruktúrális okokból.

Nem multimedia (video, radio, stb...). Hanem device status adatok (json).

Nem 100k user lesz multicastingolva hanem csak egy resze akik uo
status adatokat kernek. Valsz max 100-1000.

Akiket multicastolni szeretnétek, közöttük és a szerver között miket lehet tudni a hálózati kapcsolatról?

Üdv,
Marci

Nincs dedikalt kapcsolat. Barki lehet barhonnan.
Cloud oldalon "vegtelen" savszelesseg.

Ez esetben, gyanúm, hogy nem része a megoldásnak a multicast.

Üdv,
Marci

+1

Szia,
Szerintem gabor2 nem egészen videóstreamekre gondolt, ez alapján: http://hup.hu/node/143966#comment-1928151
Ha jól következtetek, http felett lehúzott adatokról lenne szó, de ez csak sejtés kategória :)
Amíg részleteket nem ír le, szerintem vakon tapogatózunk csak...
Üdv,
LuiseX

Igen, http stream vagy websocket. Meg nincs eldontve.

Szia,
Ebben az esetben a multicast kifejezés erősen félrevezető , mivel nektek klasszikus szerver-kliens architektúrátok van, számotokra végtelennek tűnő szerver oldali erőforrással.
Ehhez személy szerint, ha implementálható a vélt stream jelleg miatt a felvetett két lehetőségből inkább websocketet javasolnék (ha mindkét fél, a szerver és a kliensnél is megvalósítható követelmény), http stream nem feltétlenül alkalmas erre - persze fixme témakör :)
Esetleg, ha nem realtime adatblokkok kellenek, akkor egy bufferelt, periodikus lekérdezés is fedheti a megoldást (pl. az elmúlt 5 mp-et kérdezed le, proxyzva, 4mp-enként), a felhasználó részére ránézésre folyamatos, és 5mp-el van csak a valóság mögött, 1mp-es fedéssel számolva...
Persze ez utóbbi már csak egy feltételezésre épített lehetőség, több információ kellene a rendes ötleteléshez az adat jellegéről, kliens oldali feldolgozás mikéntjéről és hogy mit is szeretnél megvalósítani eleve(leírva, hogy várnád el, hogy működjön ).
Üdv,
LuiseX

+1 Websocket

(sub)

Ha websocket, akkor nezd meg a socket.io-t, elkerulod a kellemetlen meglepeteseket.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ha nem értem félre, itt nincs videofile.
Van egy JSON adatfile, amit folyamatosan streamelni kell a kliensek felé (például mert változik az adat).

Üdv,
Marci

Igy kerek. Folyamatosan valtozo adatokat streamelunk json-ben.

Szerintem ne akarj multicastolni. Maceras es nem tudod trivialisan a publikus interneten keresztul routolni. Ha HTTP-re (vagy mas jol definialt protokollra) epitesz, akkor ugyan vesztesz egy kicsit a low levelsegebol, cserebe konnyen debuggolhatova valik es konnyebb lesz fejleszteni.

Ha ebbe az iranyba mesz, erdemes megfontolni hogy legyen a protokollban switchboard lehetoseg. Ez azt jelenti hogy a kliens eloszor megkerdezi hogy hol van az o sajat szerver es oda csatlakozik, a szerverek egymas kozott pedig tarthatnak fent permanens kapcsolatot. (Vigyazat, itt csak terheleselosztasrol beszelunk, nem HA-ral. Ahhoz a szerverek kozott kell tobbsegi szavazast csinalni.) Ez eleg sok mindenben tud segiteni, meg akkor is ha elsore nem hasznalod ki, pl konnyen at tudod routolni a forgalmat egy masik adatkozpontba, stb.

Backend technologianak olyat valassz, ami nem akar kliensenkent egy processt inditani (pl PHP), mert az Isten osszes memoriaja sem lesz eleg, a geprol nem is beszelve. Olyat hasznalj, ami kepes event looppal dolgozni, tehat pl. Java, Python vagy NodeJS. (Amihez van szakertelem, barmelyik kepes ra, bar mezitlabas fejlesztokkel nem sokra mesz, ide olyan ember kell aki keni-vagja hogy alatta az OS mit csinal, kulonben nem lesz stabil / koltseghatekony.) Meg azt is el tudom kepzelni, hogy talalsz valami kesz vagy feligkesz megoldast ra, valahol PUB/SUB iranyban. Errol pl ezt erdemes elolvasni: http://highscalability.com/blog/2014/4/28/how-disqus-went-realtime-with-165k-messages-per-second-and-l.html

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Koszi a javaslatokat!

Mi a kliens? Böngésző? App? Win32 alkalmazás?

Üdv,
Marci

Meg nem eldontott pontosan, de valsz lehet :

* sima http kliens : wget, curl, python script, stb...
* browser (barmilyen es bamilyen OS)
* mobil alkalmazas (android, ios)

En inkabb a pub-sub iranyba vinnem el ezt a dolgot, csak annak streameljunk (de csunya szo ez erre, itt nem is streamelesrol beszelgetunk), akit valoban erdekel is az info. A pub-sub pont arrol szol, hogy van egy-tobb publisher, ezek publikalnak csatornakra, erre iratkoznak fel a kliensek (mindenki arra, amiely kontent erdekli), es mindenki megkapja az oket erdeklo adatokat.

Picit tobb melo kliensoldalon, eleg sok tervezest igenyel a struktura megtevezesekor, de cserebe sokkal hatekonyabb.

Ha cloud iranyban szaglalodtok, mindenkeppen nezzetek meg az Amazon SNS-t, ami pont ilyesmire valo, es kesz infra.
--
Blog | @hron84
Üzemeltető macik

Megnezzuk koszi.

Annyit mindenkepp hozzatennek, hogy a ti infratok nem streaming infra, ez felrevezeto lehet a cimben. Nektek nem egy folyamatos adatfolyamotok van (mint peldaul egy kamera folyamatosan felvett kepe), hanem gyakorlatilag olyasmi, mint egy newsfeed, sok kis, egymastol tobbe-kevesbe fuggetlen adatmorzsabol tevodik ossze a nagy adatfolyam, aminel raadasul igeny lehet a belepesi idopontnal korabbi adatok megjelenitesere is (erre kell szabni egy hatart, hogy meddig), egy stream (pl videostream) azonban baromira nem igy epul fel.
--
Blog | @hron84
Üzemeltető macik