Stream Server & Multicast support

Web, mail, IRC, IM, hálózatok

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.

( Mcsiv v | 2015. 11. 17., k – 12:19 )

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

( petyasoft27 | 2015. 11. 17., k – 12:23 )

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

( gelei v | 2015. 11. 17., k – 12:30 )

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

( Elbandi v | 2015. 11. 17., k – 12:36 )

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!

( mauzi v | 2015. 11. 17., k – 12:42 )

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.

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

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

( janoszen v | 2015. 11. 17., k – 13:15 )

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

( mrceeka v | 2015. 11. 17., k – 13:24 )

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

Üdv,
Marci

( hrgy84 | 2015. 11. 17., k – 13:41 )

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

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