Miben irnal tobbmillio useres chatet

 ( carlcolt | 2017. augusztus 12., szombat - 22:30 )

Ma el kene kezdened egy chatprogram protokolljanak/szerverenek implementalasat. Van ra realis esely, hogy tobbmillio aktiv usered lesz (elmeleti sik, de tegyuk fel).

Ami kell: webes kliens, iOS kliens (gyors es nativ, + notificationok settingekkel), Android kliens

Milyen nyelvben es milyen technologiaban, protokollokban, stb. gondolkodnal? Milyen DB-t hasznalnal?

Mi az amit, biztosan nem hasznalnal?

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ő.

Amit en biztosan tudok:

A szerver nem NodeJS es nem PHP - nincs teljesen implementalt multithread (nem, a workerek JS-ben nem eleg jok, volatile valtozo pl. nincs)

Websocket eleg jonak tunik, es konnyen megy Androidon meg iOS-en is, nemcsak weben.

Ja apro kiegeszites: eleg ha modern bongeszokben mukodik.

A weboldal tolem lehetne php-ban ;)


// Happy debugging, suckers
#define true (rand() > 10)

Az siman, de a chat daemonja hatarozottan nem abban kene legyen :P

amit hasznalnek: c++, protobuf, redis, (esetleg)kafka
amit nem: nodejs


// Happy debugging, suckers
#define true (rand() > 10)

Mar azt hittem nem vagyok normalis, hogy C++-ban gondolkodok. Tobben leszavaztak szemelyes ismeroseim kozul mert "jatekfejlesztok is csak azert hasznaljak mert muszaj a performance miatt". Pedig nagyon logikus valasztasnak tunik nekem ide. Megnyugtattal :)

Az elszaporodo nodejs pistikek es php jozsikak ertelemszeruen leszavazzak, mert segghulyek hozza, kenyelmetlennek itelik. C++ -hoz nagyon, C -hez meginkabb erteni kell, hogy az ember ne szart csinaljon.
Ha kell a performance es az ember nem akarja a vilag penzet vasra kolteni (lehet, de minek?) akkor egyertelmu a valasztas.
Egyebkent meg egy kulcsszo ami eszembe jutott, igaz c++ -hoz, de libev


// Happy debugging, suckers
#define true (rand() > 10)

Könnyebbség, hogy a websocket protokolljához is van már C library, ráadásul a linux disztribúcióban.

$ apt-cache search libwebsockets-dev
libwebsockets-dev - lightweight C websockets library - development files

Egyébként a sok-sok évnyi C után ilyen jellegű feladatokhoz éppen a Go-val szemezek. De még az elején vagyok, csak néhány egyszerűbb programot írtam Go-ban.
Fordítása gccgo-val. Performancia jónak tűnik, elsőre <10% a C-hez képesti lassulás, ennyit pedig a hülyebiztossága megér.
Makefile készíthető hozzá, így könnyű rendszergazdaként telepíteni a programomat (make && make install).

Websocket lib szintén van hozzá:
$ apt-cache search golang-websocket-dev
golang-github-gorilla-websocket-dev - Go package implementing the WebSocket protocol
golang-websocket-dev - Transitional package for golang-github-gorilla-websocket-dev

A websocketes chat programhoz itt egy alap példa:
https://github.com/gorilla/websocket/tree/master/examples/chat

Játékfejlesztők azért használnak c++-t szerver oldalon mert a kliens oldalon is azt használnak, így aki szerver oldal kódját csinálja, az a kliens oldal releváns részén is tud dolgozni (legtöbb framework c++). Kisebb indie cégeknél az életet jelenti, hogy nem kell eggyel több fejlesztő, nagyobb cégeknél meg praktikus azonos technológiát használni. Nem performance muszáj miatt.

Én C-re gondoltam. :)

Egy bizonyos méret fölött mindenképpen vízszintesen kell skálázódnod, ez meg innentől kezdve csak tervezés kérdése, a programnyelv majdnem teljesen mindegy. A klasszikus SQL alapú adatbázisokat például teljesen el kell felejteni.

Ha relatív kevés fejlesztéssel meg akarod úszni, akkor ráépítesz valamilyen vízszintesen skálázódó keretrendszerre (pl. hadoop), de ennél is jobban jársz ha inkább nem méretezel több millió userre. Nagy valószínűséggel gazdaságilag jobban megéri kidobni az egészet és újraírni akkor amikor már tényleg szükség van rá.

Lazán kapcsolódó előadás a témában:
https://www.youtube.com/watch?v=FJByltoGnA8

+1

"A klasszikus SQL alapú adatbázisokat például teljesen el kell felejteni."

ez mit jelent?

Ami egyáltalán képes valamennyire horizontálisan skálázódni, az is csak néhány tíz node-ig, globális szolgáltatás esetén csak nagyon drága megoldásokkal lehet skálázni. (vagy nagyon ügyes sharding-gal, de akkor meg elveszted az egyszerű join lehetőségét, így nem lesz sokkal okosabb mint pl. egy nosql, akkor meg minek)

Csak az sql/nosql szerintem kicsit misnomer. Ld https://cloud.google.com/sql/ - világ szinten skálázódik, de mégis van fölötte SQL *query engine*.

oké, jogos. Hadoop fölé is lehet tenni. A lényeg hogy ne hagyományos rdbms legyen, a megfogalmazás pongyola volt, szegény query language nem tehet a db architektúrájáról :)

Ezt kifejtenéd?

Nekem úgy tűnik, hogy ez egyszerűen egy menedzselt PostgreSQL / MySQL szolgáltatás. Nem látom, hogy ez miért tudna úgy horizontálisan skálázódni mint egy NoSQL adatbázis anélkül, hogy ugyanazokat a korlátozásokat használnád az adatmodellezésben (pl. sharding, key-value storeként kezelés, egyszerűen indexelt, node-ok között megosztható queryk lehetőleg joinok nélkül)

Bocs, rossz linket küldtem.

https://cloud.google.com/spanner/

ha inkább nem méretezel több millió userre.

99,9%, hogy nem lesz ennyi online useruk 5 even belul. Eddig C-ben irkaltam demonokat, ugyhogy ebben (esetleg C++) csinalnam ezt is. Ja, a tobb millio aktiv user melle erdemes lapozgatni a c10k problemarol is. A protokollrol nehez addig nyilatkozni, amig nem tudjuk a feladat reszletesebb leirasat, pl. csak text-et kuldenek a userek, vagy multimedias cuccokat is (kepek, rovid videok, ...)

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

hadoop alapu cset :DDDDDDDDDDDDDDDDD

--
NetBSD - Simplicity is prerequisite for reliability

a hadoop alapu cset még annyira nem vicces, inkább a real-time hadoop alapu :D


// Happy debugging, suckers
#define true (rand() > 10)

Meglepodtem en is hogy egy batch adatfeldolgozasra szant megoldast hova az anyamba tegyek amikor csetet fejlesztek. :)

--
arch,debian,retropie,osmc,android,windows

"batch adatfeldolgozasra szant megoldast" ez igy nem teljesen igaz, pl: "Apache Storm is a free and open source distributed realtime computation system."

-
Go konkurencia kezelés gyorstalpaló

Én a Hadoop-ról beszéltem, annak pedig semmi köze a Stormhoz.

--
arch,debian,retropie,osmc,android,windows

Akit nálam jobban érdekel a téma nézzen utána, de szerintem a Storm maximum a HDFS -ről (a hadoop high level fájlrendszeréről) tud adatot beszippantani és real time feldolgozni. Maga a hadoop (map reduce eljárása) kizárólag batch feldolgozásra alkalmas.

szerk.: a HDFS-ről elég sokminden tud adatot olvasni, de ettől még nem lesz sok köze magához a Hadoophoz.

--
arch,debian,retropie,osmc,android,windows

A kulcs jelen esetben a Yarn, ami a Hadoop szive. A Yarn schedulalja a Storm jobokat, ergo Hadoopon futtatod. A mi Hadoop disztribucionknak resze a Storm, official supportot is adunk hozza, stb. Hadoop != map/reduce ;)

-
Go konkurencia kezelés gyorstalpaló

Köszi az egyértelműsítést. Én ott kezdtem hogy a hadoop (*as in mapreduce) batch adatfeldolgozásra való, tehát nem nagyon van helye egy online chatszolgáltatásban, ami közel real time megoldásokat kíván.

--
arch,debian,retropie,osmc,android,windows

En sem Hadooppal allnek neki, de nem azert mert nem lehetne megcsinalni, rengeteg fele framework van kulonbozo feladatokra, hanem mert agyuval nem lovunk verebre.

-
Go konkurencia kezelés gyorstalpaló

"A kulcs jelen esetben a Yarn, ami a Hadoop szive. A Yarn schedulalja a Storm jobokat, ergo Hadoopon futtatod. A mi Hadoop disztribucionknak resze a Storm, official supportot is adunk hozza, stb. Hadoop != map/reduce ;)"

Ahh, vagyis Ti így használjátok, remek. Akkor maradjunk annyiban hogy nem hadoop, hanem hadoop ecosystem és talán még igaz is lehet. Kieg.: Hadoop != map/reduce != Storm


// Happy debugging, suckers
#define true (rand() > 10)

"vagyis Ti így használjátok, remek" Ez egy opcio. Sehol nem irtam, hogy a Storm jobot csak Hadooppal lehet futtatni.

"nem hadoop, hanem hadoop ecosystem" Amugy lovagolhatunk a szavakon, foleg erdemes, mivel az egesz csak egy viccnek indult. Szoval van az Apache™ Hadoop, meg a "koznyelvben" hasznalt Hadoop aka echosystem. Nem erzem, hogy nagy hulyeseget mondtam azzal, hogy lehet Hadooppal real-time adatokat feldoglozni. Amikor elmegye a Hadoop Summitra, akkor nem az Apache™ Hadoop-rol van szo 3 napig 15 teremben, hanem a Hadooprol, az egeszrol, ami messze nem egy map/reduce utemezo/vegrehajto meg egy elosztott file rendszer.

-
Go konkurencia kezelés gyorstalpaló

Nevezzünk mindent hadoop-nak és akkor megoldva. Az hogy egy hadoop summit-on beszélnek a hadoop-hoz integrálható dolgokról kb olyan, mint ha egy linux konferencián beszének az smtp-ről. Igen és?
A hadoop ennek ellenére még egy bazinagy elosztott filerendszer és map/reduce ütemező/végrehajtó marad. Kb mintha azt mondanád hogy a weboldaladat apache-ban szeretnéd megcsinálni (oké, akkor statikus html file-ok), közben kiderül hogy php-ról beszélünk


// Happy debugging, suckers
#define true (rand() > 10)

"Az hogy egy hadoop summit-on beszélnek" az pontosan azt jelenti, hogy masok fejeben is az van, mint az enyemben, hogy amikor Hadooprol beszelnek, akkor az egeszet ertik alatta, es nem konkretan az Apache™ Hadoopot, ezert nem Hadoop and Friends Summit a neve a konferencianak. (amugy kiragadott pelda)

"kb olyan, mint ha egy linux konferencián beszének az smtp-ről" koszonom, hogy szoba hoztad :) A Linux az a kernel, de mikor az emberek a Linuxrol beszelnek nem a kernelrol beszelnek. Errol annyi vita ment mar, de a koznyelv megis igy hasznalja.

-
Go konkurencia kezelés gyorstalpaló

"A Linux az a kernel, de mikor az emberek a Linuxrol beszelnek nem a kernelrol beszelnek"
Pontosan, de nem is akarják a postfix smtpd-t és az nginx webszervert linux-nak nevezni egységesen, csak mert némi köze van hozzá :)


// Happy debugging, suckers
#define true (rand() > 10)

Jah, de ha az a feladat, hogy szolgalj ki Linuxon statikus HTML-t, es te feltelepitesz/konfiguralsz egy nginx-et, akkor megoldottad a problemat vagy sem?

-
Go konkurencia kezelés gyorstalpaló

Rendben van! Nyertél! Akkor a hadoop-nál nagyobb ultimate joker a Linux szó. Kedves eredeti kérdező: a problémád megoldható linux-ban!


// Happy debugging, suckers
#define true (rand() > 10)

Igen, de a storm az egy teljesen különálló termék. Ha a hadoop-ról beszélünk, az bizony nem fog realtime adatot feldolgozni neked sehogy. A storm pedig egy teljesen különálló framework (az elején pedig teljesen saját resource manager-el dolgozott), majd integrálták resource manager-nek a yarn-t, pont (aminek a használata egyébként nem is kötelező, mert futhat teljesen külön)


// Happy debugging, suckers
#define true (rand() > 10)

"majd integrálták resource manager-nek a yarn-t" Tehat ha van egy Hadoop clustered, akkor tudod hasznalni a Stormot real time adat feldolgozasra vagy sem?

-
Go konkurencia kezelés gyorstalpaló

Ha nincs hadoop clustered, a stormot akkor is tudod real-time adat feldolgozasra hasznalni.


// Happy debugging, suckers
#define true (rand() > 10)

a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'a'

-
Go konkurencia kezelés gyorstalpaló

b! :D


// Happy debugging, suckers
#define true (rand() > 10)

ha van egy hadoop clustered, akkor meg tudod csinalni ket gep munkajat szaz gepen :)))

--
NetBSD - Simplicity is prerequisite for reliability

vagy nem :DDD


// Happy debugging, suckers
#define true (rand() > 10)

+1, szerintem is a legjobb megoldas, hogy kevesebb userre meretezed, es kiadod az MVP-t hamarabb, aztan ha elkezd felfutni, akkor ujrairod megfeleloen skalazodora a jelenlegi tapasztalatok alapjan.

Ha stabil kell, akkor C, C++. Mezei socketek, semmi extra. Persze jól kitesztelve, segfault mentesen.
JAVA-ban se nehéz megírni, de ahhoz nem árt ha van vasad :D
NodeJs jó cucc, de nem biztos, hogy használnám erre, persze ki is zártad.

Ami viszont lényeg:
Szerintem nem feltétlenül maga a program számít, nem nagy dolog egy chates socket szervert összedobni.
Egy darab program tuti nem vinne stabilan több millió online usert. A program fölé kell tervezni egy rendszert ami foglalkozik az erőforrásokkal, és szálakat hoz létre, párhuzamos futtatásra. Sőt, még a több szerveres megoldás se lenne rossz szerintem, akár virtuális gépeken is. Tehát több párhuzamosan futó szerver, azon belül pedig párhuzamosan futó szálak.
Érdemes konfigurálhatóvá tenni az egészet, így a konfig átírásával tudod méretezni az egészet. Attól függően, hogy mekkora terhelésre számítasz.
A megvalósítás részletkérdés: Pl a kliens dönti el, hogy melyik szerverhez csatlakozzon, azon belül melyik szál portjához (terheléstől függően), vagy a kliens csak egy terheléselosztó szerverhez csatlakozik és az a belső hálón eldönti, hogy melyik alszerverhez, azon belül melyik szálhoz dobja be a klienst. Kívülről ez rejtve marad. De ez már megvalósítás kérdése.

Most olvasom közben, hogy DB-t is kérdezel. Valaki írta a Redis-t. Az nem rossz megoldás, pl szobák tárolására. A kommenteket nem tárolnám benne. Ha kell archiválás, akkor már egy sql-es "lassú" db is megfelel (persze ott se rossz ha van valami rotálás, nem biztos, hogy van értelme letárolni egy kommentet több évre, sőt...)

A java továbbra is annyira iszonyú erőforrászabáló, mint ami volt 5+ éve?
Vagy voltak esetleg - nagyon - pozitív változások?

Miért lenne az? A világ HFT rendszereinek nagyrésze Java. Ha a lassú desktop appokra gondolsz, az tök más tészta. Szerveren a Java rendkívül gyors tud lenni, miért is lenne lassú? GC stratégiától függően relatíve sok RAM kellhet neki, cserébe kb. 0 költségű memóriafoglalást kapsz, meg lényegében egy slidert a throughput/latency között. (A G1 kollektor egész szépen kezeli a sok memóriát, tehát nem probléma akár a terabájtos heap sem.)

----------------------
while (!sleep) sheep++;

soha nem is volt az

--
NetBSD - Simplicity is prerequisite for reliability

Valszeg a Java is olyan mint a php. Szakavatott kezekben dorombol, de kóklerek kezében halálos fegyver. Ez utóbbi a gyakoribb szerintem.
Van egy rendszerünk amit külsős csapat fejleszt. Weboldal mögötti backend. Java-ban. Ocsmány szar. Látogató nincs rajta sok egyáltalán, de volt amikor bezabált 10-15GB memóriát. Valamit szarul csináltak meg. (valami jetty-s cucc pörög alatta).
Manapság a fejlesztők zöme nem képes optimalizálni, mert sokuk alá odateszik a vasat. Nálunk legalábbis ez van.

Ugyanez megy a játékfejlesztésben is. Elég megnézni, 20 évvel ezelőtt oda kellett figyelni minden kB memóriára, ma már aszondják a játékfejlesztő cégek, hogy vegyél jobb VGA-t.

Tegyük hozzá, hogy a szoftverek jól el is rejtik a mai kódmunkás elől az optimalizálás lehetőségét. A keretrendszerek ellenőrizhetetlen dolgokat, kódokat csapnak hozzá a késztermékhez, stb. Azután jött a gyors fejlesztés, mint követelmény. Nincs is idő alapos optimalizálásra, rövid határidőket szabnak a megrendelők, így a fejlesztők olyat szállítanak, amit ennyi idő alatt létre lehet hozni és hozzá teszik: vegyél nagyobb vasat!

Igy van. A fejlesztő meg hiába sír, hogy legalább teszteket csináljunk, meg mérjünk, meg akármi, nem, az nem fontos. A csillió+1-edik, senki által nem használt feature,
az a fontos.

A Java pont olyan erőforrás zabáló, mint 5 vagy 10 éve volt... viszont nagyságrendekkel jobb, mint 20 (!) éve. Imádom, amikor az emberek ennyire a régmúltban élnek.

Ugyanolyan mint 5 éve. Szerver oldalon, warmup után, normális kezek között hasít.

--
arch,debian,retropie,osmc,android,windows

+1
Gyuszk-al karöltve maszíroztunk olyan rendszert, ami backend oldalon Java és óriási terheléseket visz el mind a mai napig. (mondom ezt úgy hogy én egyébként be vagyok oltva java ellen :D)
Nem rossz az, csak hozzáértő kezek kellenek ahogy ő is mondta ;)


// Happy debugging, suckers
#define true (rand() > 10)

A WhatsApp-ot Erlang-alapokon írták, pár száz millió usert elvitt. A Slack Java. FB messenger Erlang/PHP/C++.

----------------------
while (!sleep) sheep++;

En a helyedben a Telegram [ https://en.m.wikipedia.org/wiki/Telegram_(messaging_service) ] fejlesztőire dobnék egy e-mailt pár kulcskérdéssel.

100+ millió usert szolgál ki és a leggyorsabb+legstabilabb chat szoftver amit életemben használtam.

+1

+1

Scala + Akka - backend
React + Redux/Relay - frontend
Kotlin / ReactNative + Redux/Relay / ?Flutter? (valszeg meg nem eleg kiforrott) - mobil

Ha React/ReactNative, akkor Material UI look & feelnek.

Kafka jol hangzik messagingnek.

+1 a Scala-Akka kombóra, vagy esetleg erlang/elixir (zseniális dolog)

Adatbázisra a voltdb-t hallom emlegetni hasonló kontextusban, meglesném.

Van valamelyikkel konkrét tapasztalatod? Erlang érdekelne.

Odalent mono gui meg php. Meg indítani kell egy websocket
------------------------
Jézus reset téged

MongoDB erre nem a legjobb választás.
Meg a PHP sem.
És a kliens oldalon ugyan csak egy websocket connection, de a server poolban már pár millió.

subs

Sajnos a tobb millio user mint olyan nem mond semmit. Ha tobb millio user van benne, de alig beszelgetnek az tok mas terheles lesz mint tobb millio user aki mint aki megorult nyomkodja a billenytuket. Azt is erdemes elmondani, hogy ha ez nem egy mar meglevo chat szoftver csereje, akkor erdemes megfontolni, hogy nem ekkora meretekben kell indulni. Sokszor az uzleti vezetok szeretnek nagyot almodni, de egy tobb millio userre felkeszitett chat teljesen maskepp epul fel mint egy par tizezer useres es sokkal sokkal tobb idobe es penzbe kerul.

Most hogy ezt tisztazzuk, nezzuk a gyakorlati oldalat. Nagyobb chat szolgaltatok kozul joparan XMPP-re (Jabberre) epitenek. Ehhez temerdek library es szoftver van, szoval nem kell mindent ujra kitalalni. Raadasul letezik horizontalisan skalazodo szerver oldali technologia hozza. A hatulutoje viszont az, hogy nagyon komplex a technologia, es nem fogod meguszni az extensionok implementalasat. Az XMPP nehany problemajarol a ChatSecure alkotoja irt reszletesebben es erdemes a blogban visszatekerni. Egy multbeli hasonlo projektekbol elmondhato az, hogy a kovetkezok biztosan fognak nemi fejfajast okozni:

- XMPP-ben a chatek perzisztens tarolasa a kliens feladata. (XEP-0136)
- XMPP-ben (tudtommal) a chatek amolyan session-stilusban mennek, klienstol fuggoen az uzenetek nem kerulnek kezbesitesre minden eszkozre.
- Push notificationok a kliensekre.

Persze azt is csinalhatod, hogy nullarol elkezdesz irni egy chat megoldast, ez esetben meg kell oldanod mindazt amit az XMPP mar sikeresen megugrott, pl. uzenetek routolasa, presence uzenetek, stb stb stb.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

+1, ilyet biztos nem írnék nulláról.

Én céltól függően még azt is megnézném, hogy a feladat nem oldható e meg egy létező szolgáltatás tetején. Gyakorlatilag minden nagy cégnek van már chat-je. És minden nagy cég ezen pörög (MS, Apple, Google, Facebook stb.). Ha nem kifejezetten chat-tel foglalkoztok, akkor egyszerűbb lehet egy Google Hangouts/Facebook Messenger/Skype (ha onsite kell tartani az adatokat Microsoft Lync) tetejére integrálni azt, ami esetleg hiányzik.
--
http://naszta.hu

+1 pl. salesforce social media connector, összefogja az összes elterjedt platform chat-jét és megkapod std api-ban, rá tudod rakni a saját okosságokat.

Koszi mindenkinek, 3 dolog merult fel, amiknel tovabbi reszletekre kerdeznek:

1. Funkcionalis nyelvek: scala, erlang. Tenyleg "megkerulhetetlenek" ezen a mereten? Van valami amit abban meg tudnek oldani bennuk es C++-ban nem es jo esellyel szukseges?

2. DB - tobb NoSQL felmerult, es ertheto is, hogy klasszikus SQL itt nem fog mukodni. Egyik szempont ugye, hogy ekkora meretben foreign key-ek felejtosek, masreszt jobb, ha a db ugy van tervezve, hogy "abbol torolni nem nagyon fognak" (ez utobbi mondjuk pont igaz a Facebook mysql forkjara is). MySQL-nel es PostgreSQL-nel meg csak olyan replikaciot lattam, ahol egyvalami tudott irni, tobbvalami read only slave volt. A sokat emlegetett "horizontalis skalazas" tobb gepre szepen hangzik, hogy tobb gep tudjon irni, de felmerult bennem tobb reszletkerdes:
-mig gepen belul a tobb CPU mag elintez egy atomic/volatile valtozot par microsec alatt, egy modern SSD-re irni se olyan veszes mar flush-kor, addig a masik gep fele ahova "horizontalis skalazok" megy egy (jo par) TCP csomag, meg tegyuk fel 2 msec latency es 1 Gigabit. Van valami szamitas arra egy letezo NoSQL db mukodoeset figyelembe veve, hogy mi az az adatbazis meret es irasi gyakorisag, ahol mar ez megeri (vagy ahol mar csak ez mukodik)?
-masik kozelito megoldas amire gondoltam: chat resztvevoibol hash es azalapjan annyis maradek ahany gep van, a db-knek nem is kell tudniuk egymasrol, kiveve amikor "uj gepeket nyitok" es sync van (viszont lehet ez a sync nem lesz eleg gyors/sync alatt problemas lesz hasznalni)

3. XMPP, WSS eleg jo lesz nekem?

Nincs olyasmi, amit funkcionális nyelvekben meg lehet oldani, de C++-ban nem (és vice versa). A kérdés inkább az, hogy milyen mintázatokat "sugall" a nyelv (vagy framework).

Példa: Clojure alatt lényegében minden érték alapból immutable, ami nem, azt tranzakcionalis szemantikaval változtathatod, lock nem létezik a nyelvben (egyszerűsítek). Ennek egész brutális előnyei/hatásai vannak -- a versenyhelyzetek, adatkorrupciók kb. eltűnnek, helyettük inkább a ritkán előforduló, magas kontencio esetén létrejövő starvation, etc. a probléma. Namost ha ez szimpatikus, akkor vagy funkcionális nyelvet használsz, vagy C++-ban csinálod ugyanezt, de úgy sokkal több melót kell belefektetni.

Egyáltalán nem fekete-feher a probléma. Chat esetén (erősen párhuzamos események, információk passzolgatasa rengeteg logikai actor között) én beprobalnam a Scala/Play kombót, vagy Clojure-t, vagy az Erlangot.

----------------------
while (!sleep) sheep++;

A Clojure lenne az utolso, amihez nyulnek (Scala-t Erlangot nem zarnam ki viszont).

Nyilván azt használsz, ami jól esik, csak azt akartam mondani, hogy bármiben lehet bármilyen stílusban programozni (csak nem feltétlenül érdemes).

----------------------
while (!sleep) sheep++;

Idézet:
3. XMPP, WSS eleg jo lesz nekem?

Mi a feature set amit meg kell valositani? Sima szoveges uzenetek? Vagy legyen benne Facebook-stilusban embedded media? Lehet esetleg formazni az uzenetek? Kell-e tarolni az uzeneteket a kliensek kivetelevel? Kell-e end-to-end titkositas? Kell-e tudni csatolmanyt kuldeni / es permanensen tarolni? Kell-e biztonsagos letolto link amit nem lehet megosztani a csatolmanyokhoz? Honnan tudod hogy tenyleg userek millioi lesznek? A userek millioi hany uzenetet fognak kuldeni az elozetes tesztek szerint? Hogyan azonositod a usereket? Lesz-e egynel tobb kliens egy usernel? Milyen kliens lesz? Webes vagy alkalmazas? Milyen technologiakhoz van szakertelem a cegnel? Es meg millio kerdes felmerul bennem.

Lehet hogy annyira specialis kovetelmenyeid lesznek, hogy tobb energia azokat XMPP-ben megvalositani, de az is lehet, hogy gyk. egy az egyben az kell neked amit az XMPP vagy az IRC mar tud. Szoval ennel sokkal tobb info kell, mert igy egy zsak tanacsot fogsz kapni es korant sem biztos hogy a Te esetedre alkalmazhato lesz barmelyik is.

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

Google Firebase. Automatikusan skálázódik, igaz 1 millió usernél már biztos nem két forint. Cserébe nem kell csak a klienst fejleszteni.

A kliens fejlesztese az a legkevesebb. Itt a szerver oldal az pont, ahol eros engineering szukseges.

Ha jól értem, spyff éppen arra utalt, hogy a szerver ekkor a Google gondja, neked csak a klienssel kell törődni.
Én nem értek ilyen rendszerekhez, de ha nekem kellene csinálni, biztos firebase-zel próbálkoznék és nem állnék neki bármilyen nyelvben programozni szervert, iOS, Android, web klienset. Persze akkor, ha valamiért nem kell ragaszkodni a saját szerverhez.

--
Soli Deo Gloria

Igen, erre érettem. Egy délután alatt össze raktam vele egy kis chat progit. A firebase rész alig pár sor benne. Ami előny, hogy nem kell protokollt programozni, alapból titkosított TLS csatornán a kliens-szerver kommunikáció (nyilván az üzenetek ezen felül még titkosíthatók, p2p titkosításhoz is).
Sebességről annyit, hogy egy tabletről 10 milliszekundumonként küldtem 1000 bájtos üzeneteket. Egy sem veszett el, a másik tablet meg egy emulátor mindet megkapta, átlagos válaszidő kb. 200ms, de a jitter sem volt több 30ms-nél. A kapcsolat megszakadást, újraépítést szépen megoldja a háttérben, addig maga cacheli az elküldött üzeneteket és ha újra feláll a kapcsolat, burst-ben felküldi. Simán tudtam chat közben Wifi-LTE között váltogatni, nem halt szét - annak ellenére, hogy egy sor hálózatkezelés kódot nem írtam.

Lehet integrálni cloud functionnel is (AWS lambda Google megfelelője. Úgy mondjuk picit drágább a dolog, meg növel a válaszidőn is). Ez is automatikusan skálázódik, használható pl. özenetek felhős feldolgozására.

-

Én egy MQ-t raknék alá, ActiveMQ, RabbitMQ. A nyelv az mindegy onnantól, az csak a fedőszerv.

Jabbert is lehet, van erlangos (ejabberd). Az erlang otp lib aokat tud az ilyenekben segíteni amúgy.

De volt pythonban is HA lib, twisted volt tán a neve.

Neki lehet állni baltával C-ben csak minek.

AMQP? Lassú és halott protokoll. NATS, Kafka, ezek lehetnek érdekesek elosztott time-series adatokra.

----------------------
while (!sleep) sheep++;

https://content.pivotal.io/rabbitmq/understanding-when-to-use-rabbitmq-or-apache-kafka

Itt ranezve a kewt kepre nekem jobban tetszett a RabbitMQ mint a Kafka, utobbihoz kell egy "primary broker"

Próbáld ki őket. A Kafka skalazodasa konkrétan két nagyságrenddel jobb, mint pl a RabbitMQ-e (ez egy nagyon általános kijelentés, de nézz utána, próbáld mi). A Kafka bizonyítottan képes egyszerre 10-100 terabájtos elosztott adatbázisként és nagyon gyors queue-kent működni, a Rabbit egyiket sem tudja.
A Kafka esetében sem kell SPOF.

----------------------
while (!sleep) sheep++;

Akármi. Én csak azt tudom, hogy a publish-subscribe nagyon jól modellezi az összes ilyet, amik otthagyták a jabbert (XMPP-t), azok mind valami MQ megoldás felé mentek, ahol minden beszélgetés egy queue.

Egyetemen meg azt tanultam, hogy ne akarjak magamnak MQ-t írni, mert játszásiból nagyon könnyű (írtam is), de skálázóra írni baromi nehéz, vegyek le egyet a polcról oszt szevasz. Olyan mint az adatbázis szerver üzleti szoftvernél, azt se írsz mert minek.

Míg a jabber megkülönböztetett presence, sima direkt meg chatszoba-üzeneteket, és csak az utóbbi ment PubSub alapon, addig az MSN meg az IRC protokoljai a fentit csinálták (csatornanyitás mindenre), és hát mindenhol szép sorban kib.szkodták az XMPP backendeket egy idő után - FB, Google, WhatsApp, ezek mind XMPP-kompatibilisek voltak régen.

Szóval szerintem a backend fordítson le mindent MQ-ra, és legyen kb. kérés- (kérész :) életű benne minden processz. Innentől kezdve meg akár (nemröhög) PHP is lehet.

Azért ezt olvasd el, mielőtt bármit is választasz:
http://www.kegel.com/c10k.html

Koszi, fentebb sj is emlitette, mar akkor elkezdtem utananezni es olvasni. Hasznos

+sok
nagyon tanulsagos iras. anno azt hittem irok 10 perc alatt egy egyszeru (1db static oldalt kiszolgalo) webservert, aztan hamar kiderult, hogy nem is olyan egyszeru :)

nalam 4000-nel allt meg a tudomany(nem http szerver). De ez nagyon regi emlek, hogy mi fogyott epp el. Egyszerubb volt a userbaset korlatozni, hogy 4-5k alatt legyen.
Azert 4k nyitott tcp socket nem piskota.

Mondjuk azota eltelt par ev...

Szerintem a kapcsolatok kezelesere van kesz megoldas manapsag. En biztos irodalomkutatassal kezdenem, mielott valamelyik kulfoldi kolleganak atpasszolnam:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Hasonlóan érdekes Avi Kivity (korábban KVM, OSv fűződik a nevéhez) előadása a ScyllaDB-ről: https://www.infoq.com/presentations/scylladb

Maga a ScyllaDB egy dron-in kompatibilis Cassandra klón csak nagyságrendekkel gyorsabb - az előadásban arról beszélnek, hogy milyen architektúrával érték ezt el.

Köszi, ezt nem ismertem, de nagyon jónak tűnik!

A drop-in kompatibilitás akkor igaz, ha 2.2 a Cassandra verziója semmi extra feature nincs használatban, aminek van Java érintettsége (Java trigger, user defined function, satöbbi) és a "nagyságrendekkel gyorsabb" se jön ki egyértelműen, csak erős peremfeltételekkel. Az ötlet ugye az volt, hogy a C++ az mennyivel gyorsabb, mint a Java, csak a valóság az, hogy nem lett gyorsabb... sőt, nagyobb terheléseknél a ScyllaDB minden előjel nélkül összeomlik, a Cassandra csak belassul.

Ott van az irc mint backend, csak a frontendet kell megirni. Brutalis méretű hálózatok vannak rajta, jol skalazodik. Futtathatsz, sajat szervereket. Logolni pedig, ha igeny van ra akkor tudsz a deamonokon keresztul.

---...---
TLoF

IRC-t akartam én is mondani. '99-ben több milliós felhasználószám volt IRC-n. Belegondolva hogy milyen vasak és hálózatok voltak akkoriban, mai infrastruktúrán nagyon szépen kell hogy muzsikáljon. Vagy XMPP?

Utána olvasva: IRC egyidejű aktív user rekordok, 6m 2001-ben, 10m 2003-ban.

Kisgatyaban, fulbevaloval, szovegszerkesztoben. Nagyjabol.

http://karikasostor.hu - Az autentikus zajforrás.

Hehe, én is erre gondoltam elsőre :-)

Csak én Donald Kacsának öltözve csinálnám: http://szleng.blog.hu/2009/02/14/donaldkacsazik

CUDA :)

[Feliratkozás]

+1

+1

+1


Sic Transit Gloria Mundi

Ami kimaradt, hogyha a backendet sikerult jól megcsinalni, akkor a kliensek csatlakoztatásat meg lehet csinalni go daemonokkal. Jol programozható, eléggé hülye biztos és a skalazodik. Tud web socketet, es minden mai divatos mq megoldást.

---...---
TLoF

ha mar nodejs:
egy 2015-os cikk 600k kapcsolat kiszolgalasara websocket es nodejs alapon:))

https://blog.jayway.com/2015/04/13/600k-concurrent-websocket-connections-on-aws-using-node-js/

Szerintem irdd meg random nyelven, es amikor elered a 100k felhasznalot akkor vegyel fel egy programozot;)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Troll: összehívnám az összes potenciális felhasználót egy konferenciaterembe, és azt mondanám nekik: Jocó, Fecó, ti ketten telefonon tartsátok a kapcsolatot egymással.

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

Az n+1 megírása nekem olyannak tűnik mint a forró víz feltalálása... nem lenne egyszerűbb egy meglévő daemon-t választani és szépen megírni hozzá a klienseket??

+1

Nem biztos hogy ezek közül bármelyik is alkalmas több millió embert kiszolgálni / skálázódni / stb. A legtöbbje valószínűleg 90-es és 2000-es évekből maradt fosszília, ami az IRC párszáz, maximum párezer használóját kiszolgálja. De nem néztem át tüzetesen. Mindenképpen valamilyen nagyon aktuális cuccot vetnék be inkább.

--
arch,debian,retropie,osmc,android,windows

Mint fosszília annyit tennék ehhez hozzá, hogy régen igen komoly IRC hálózatok voltak igen kemény forgalommal és még ma is bőven sokan használják. Megint az a titka a dolognak, hogy ha jól összerakják, a skálázódást szem előtt tartva, akkor menni fog az. Az megint más kérdés, hogy az IRC főleg a szoba/közösség alapú szerveződésekre ment rá és nem a person-to-person csapásirányra, ahol néha behívsz röbb résztvevőt. Egyébként ez utóbbira pedig ott a Jabber. :)

(Én ugyan még sosem cseteltem, de azért érdekelne, hogyan veszett ki az emberekből (legalábbis a többségből) az IRC használatának képessége az elmúlt húsz évben. (Egyébként pl. a prog.hu is tele van különféle ifjú titánok 'webes chat-et szeretnék' topikjaival.))

(tröll)
Ha azt kérdeznéd, mit használnék... a helyes választás természetesen az Outlaw Techno Psychobitch, rövidítve: OTP.

A kétkedőknek itt egy tudományos kisfilm:
https://www.youtube.com/watch?v=rRbY3TMUcgQ
(/tröll)

Teljesen felesleges komment: https://www.youtube.com/watch?v=9Z9h8lGZsX8

haha,ez jó volt

A kis melegítőmben pl a gép előtt ülve.

Én is a meglévő technikákban gondolkoznék, valami HTTP(S) feletti protokollt használva, ami jó sansszal átmegy proxy-n, céges tűzfalon (ha csak direkt a szervereidet nem blokkolják), többszörösen NAT-olt mobilneten ésatöbbi. Az se baj, ha már vannak hozzá kész kliensek, csak a szolgáltatást kell beizzítanod, saját szerveren/felhőben. Nem vagyok jártas chat-ben, de tuti van ilyesmi.

golang

Ja, a tippem: használj Mátrix/Riot párost, és kész.

----------------------
while (!sleep) sheep++;

+1
Sőt, kicsit jobban is meg lehetett volna nyomni azt a matrix.org -ot. A "How does it work" résznél van pár szép leírás ami ötleteket adhat a tervezésben. Példák és próbák is szép számmal beszerezhetőek mind kliens mind kiszolgáló oldalra.

Amúgy ebből az apropóból ismét ránéztem a Prism-break -re. ( https://prism-break.org/en/all/#instant-messaging )

Illetve anno innen kiindulva pár hónapja a Wire tetszett még meg ( http://alternativeto.net/software/wire/?license=opensource ). Bár volt rá nyilatkozat hogy megnyitják a server oldalt is, de úgy tűnik inkább a fizetős szolgáltatásokat próbálták bevezetni azóta.
A github oldalukon azért van pár ábra, hogy ők kb. hogyan, merre-meddig. ( https://github.com/wireapp/wire-server )

Ez még nem biztos hogy jó.

Amúgy meg a kérdezőnek: Hajrá! Szívesen látnék már egy teljesen java mentes megoldást egy ilyen volumenű dologra.

--
RudyD

Szerintem: elindulnék a koncepcióval, hogy egyáltalán működik-e a piacon és ha dől a pénz az egymillió potenciális felhasználó miatt, akkor vennék kilóra pár sovány matematikust és egy-két fejlesztőt és ők majd megírják skálázhatóra. Persze, lehet álmodozni arról, hogy majd mekkora terhelés lesz és évekig lehet fejleszteni titokban a Halálcsillagot, csak ugye az lesz ebből, hogy valami közbejön és a szellőzőnyíláson át felrobbantják az egészet. A hídon akkor menj át, ha odaértél.

+1

És ha már ott tart, hogy dől a lé? Csak épp a kilóra vett informatikus nem tudja, hogyan kellene, és ezért kérdezik a HUP-ot :).

Ez egy teljesen életszerű eset... :D

Ha ez az eset van, akkor lenne kicsit pontosabb requirement ;) Latszolag annyi a specko, hogy "Miben irnal tobbmillio useres chatet".

-
Go konkurencia kezelés gyorstalpaló

Ezzel a megközelítéssel van egy olyan probléma, hogy ha bejön a biznic, akkor mindenki ki akarja próbálni _azonnal_. Amikor berobban a népszerűség-bomba, akkor már késő reagálni, nincs idő. Na most, ha ekkor automatikusan aláprovisioningolsz pár virtuális szervert és minden fennakadás nélkül alacsony latency-vel működik, akkor az emberek rákapnak.

Ha meg belassul, akkor megállapítják, hogy ez szar, és a brandnek annyi.

Így járt az iWiw: amikor megugrott a látogatottság belassult, és képtelenek voltak begyorsulni. Még újra is írták Java-ban, hogy gyorsabb legyen (LOL). Ha nem lassult volna be, még ma is fél Magyarország iWiw-ezne és nem Facebookozna :-).

Bár biztos vagyok benne hogy az 1.4-es időkből származó mémnek igazak voltak, de így 1.9 fele aki lassú kódot ír Java-ban az szimplán nem érti mit csinál ^^

> még ma is fél Magyarország iWiw-ezne és nem Facebookozna

Nem értek egyet, amikor megtörtént a váltás a facebook azon kívül hogy sokkal szebb volt, sokkal hatékonyabban lehetett rajta csajozni, ami az egész lényege. Böködés és a többi. A Google Plus masszívan jobb szolgáltatás volt a facebooknál amikor megjelent, de a nőket nem sikerül behúzniuk így nem nagyon érdekelt senkit a mérnökökön kívül.

"Ezzel a megközelítéssel van egy olyan probléma, hogy ha bejön a biznic, akkor mindenki ki akarja próbálni _azonnal_."

Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni...

"Na most, ha ekkor automatikusan aláprovisioningolsz pár virtuális szervert és minden fennakadás nélkül alacsony latency-vel működik, akkor az emberek rákapnak."

Aha... hány ilyet csináltál már? :)

"Így járt az iWiw: amikor megugrott a látogatottság belassult, és képtelenek voltak begyorsulni."

Ott alapvetően pénzhiány volt éveken át, mert nem tudták a forgalmat pénzre váltani.

"Még újra is írták Java-ban, hogy gyorsabb legyen (LOL)."

LOL persze... gondolom fogalmad nincs, hogy mi volt Java és miért volt Java és mi nem volt Java. És arról sincs fogalmad, hogy miért használnak Java-t ilyen célokra.

"Ha nem lassult volna be, még ma is fél Magyarország iWiw-ezne és nem Facebookozna :-)."

Nem a sebességével volt gond, hanem azzal, hogy nem nemzetközi porondon elvérzett a magyar piac meg kicsi.

„Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni...”
BKK elektronikus jegyrendszer?

a kávém! :-D
--
blogom

Köszönöm, ez jól esett.

:-D

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..."

nem tud, mert azok definíció szerint nem futottak fel ;)

(rejtett sub)

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..."

Pokemon Go sokáig szenvedett például :). Mondjuk nem teljesen a felvetésre válasz, mert ezt azért rendesen megtervezték, csak elszámolták. Ahogy pl. sok magyar közigazgatási rendszerrel is előfordul. Egyik se úgy indul, hogy ezt most direkt szarul írjuk meg, csak így sikerül.

"Nem a sebességével volt gond, hanem azzal, hogy nem nemzetközi porondon elvérzett a magyar piac meg kicsi."

Na ezt sose értettem. Egy időben a WIW beszélt angolul. Pont azért lett IWIW, mert international. Hívtam is volna rá külföldi ismerősöket. Aztán egyszer csak eltűnt az angol nyelv. Lehet, hogy a jó értelemben vett felrobbanástól féltek, másként nem nagyon tudom elképzelni, miért butították le direkt.

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..." egy rakás "slashdotted" oldal van. Hirtelen jönnek a látogatók, aztán nincsenek kiszolgálva. Instant bukó, az emberek 99%-a másodszor nem kattint rá. Hallani nem hallunk róluk, mert ugye nem lesznek híresek.

"Aha... hány ilyet csináltál már? :)" nem csináltam, de ha arra számítanék, hogy fel fog futni, akkor így kellene tervezni. Máskülönben bukó lesz a felfutáskor. Ha dőlnek az emberek ki kell őket szolgálni, mese nincs.

Konkrétan a Facebook pont azt csinálta jól, hogy skálázódott a felhasználókkal, amióta először láttam sose lassult be.

Nem a Java a LOL, hanem az, hogy majd attól önmagában gyors lesz. Ha nem sikerül a skálzódás léptékét megjavítani, akkor tökmindegy miben van, lassú lesz.

Oké, az talán túlzás, hogy ma is iWiw-eznénk, de egyérteltelműen volt egy időszak, hogy mindenki be akart lépni, és épp akkor baromira belassult. Én azt tippeltem akkor, hogy nem tud skálázódni. Mert ha tudott volna, akkor nem lettek volna akkora marhák, hogy ne toljanak alá plusz szervereket. A T vette meg, ha jól emlékszem, nem hiszem, hogy pénzhiány lett volna. Ha nem lassult volna be, akkor tuti, hogy növekedett volna még egy darabig.

(Kivéve, ha direkt azért vette meg a T, hogy kivéreztesse - volt már erre is példa a világtörténelemben.)

+1

"Hirtelen jönnek a látogatók, aztán nincsenek kiszolgálva. Instant bukó, az emberek 99%-a másodszor nem kattint rá. Hallani nem hallunk róluk, mert ugye nem lesznek híresek."

Na, mint például?

"Konkrétan a Facebook pont azt csinálta jól, hogy skálázódott a felhasználókkal, amióta először láttam sose lassult be."

Konkrétan a Facebook pont szar volt eleinte, csak annyira kicsi volt, hogy senkit nem érdekelt, hogy lassú... simán elindultak puszta MySQL és PHP alapokon és mire felfutott 3-4 év alatt, addigra már rég megoldották a skálázódási problémákat... :)

"Nem a Java a LOL, hanem az, hogy majd attól önmagában gyors lesz"

Pedig sokat segít...

"A T vette meg, ha jól emlékszem, nem hiszem, hogy pénzhiány lett volna. Ha nem lassult volna be, akkor tuti, hogy növekedett volna még egy darabig."

Nem volt lassú... én a kétezer-valahányadik felhasználója voltam, láttam a kezdetek óta, nem volt lassú. Inkább szimplán szar és feature szegény volt, főleg, miután telenyomták borzasztóan zavaró reklámokkal.

Hirtelen jönnek a látogatók, aztán nincsenek kiszolgálva. Instant bukó, az emberek 99%-a másodszor nem kattint rá. Hallani nem hallunk róluk, mert ugye nem lesznek híresek.

Így van, az emberek nagyon érzékenyek a késleltetésre (latency). Van is erről egy jó írás.

"Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition."

"Mondj már olyat, ami olyan gyorsan futott fel, hogy nem tudták volna közben háromszor újraírni..."

Ello

Ello? Hol van itt a hirtelen felfutás? :)

Vegul sehol, de 20 ismerosom is vegul kapott invite-ot es ott hagyta mert lassu volt es be se toltott

Az Ello (kozossegi oldal) meg jobb pelda mint az iwiw: a marketingesek elertek mindenkit, csillagos otosre vizsgaztak, a dev team meg egyesre a lassu valaszidokkel.

Szerintem azért meg kéne nézni több faktort is.
Az fb is elitista meghívásos alapú közösségként kezdte, lehet hogy ez is volt az egyik nagy vonzereje.
A g is mikor elindította a levelezését, az is csak meghívóval ment.
Gyakorlatilag megvolt a megfelelő folyamat és lehetőségük volt csak annyi terhelést beengedni ami még nem vágta haza az egész üzletet.

Valahol mindkettőt a gondolkodás nélküli kapzsiság pörgette túl a peremen.
Bár kétségkívül nem a fejlesztőit akarom védeni, de ha egy márkanév bedöglik akkor ott máshol is lehet keresni a valódi felelősöket.

A fejlesztést, kódolást, marketinget és az üzemeltetést egyensúlyban tartani sem lehetetlen, csak a megfelelő gondolkodással és módszerekkel és visszacsatolással kell megtenni.
--
RudyD

VueJS kliensen Akka szerveren MongoDB üzenet tárolásra. Mobil kliensek natívan. Kommunikáció WebSocket ofc.

Tutoriallal már meg is írták Neked! :-)

That’s it. Were done. Now we have a, very simple, but scalable, fault-tolerant, event-driven, persistent chat server that can without problem serve a million concurrent users on a regular workstation.

Akka, vagy más actor rendszer helyett valamely message broker (Kafka, *MQ) rendszer használata lehet még egy jó és könnyen járható megoldás.

Erlangban. Voltmar?

(Egyebkent minek ujra feltalalni a spanyolviaszt, ha nem muszaj, lasd pl. https://www.ejabberd.im, de nyilvan ezeket a koroket mar lefutottad, csak ugy eszembe jutott :))

Multithread?? Hát egy több millió user-es chat esetén a multi thread lenne az utolsó dolog amit kipróbálnék. Mindenképp async io-ban gondolkoznék. IPC-re redis vagy zqm vagy rabbitmq.

Prototyping python+asyncio vagy python+tornadoweb, és ha működik akkor átírni natív szervert c++ -ba.

Az is kérdés, hogy ez "csak" egy chat, vagy lesz benne szociális háló, vagy valami ami hálósan összeköti ezt a sok embert? Mert ha lesz, akkor még egy adatbázis kell, ami elosztott és hálósan lekérdezhető.

Multithread? Mi baj a multithread-el? Ráadásként a multithread és az async io egyáltalán nem zárja ki egymást, sőt


// Happy debugging, suckers
#define true (rand() > 10)