Pulse - asinkroni PHP za dvosmjernu komunikaciju server-client

Po tvojoj definiciji dvosmerne komunikacije, zasto onda obican HTTP request → response nije dvosmerna komunikacija? Isto klijent posalje pitanje, server mu odgovori, znaci komuniciraju dvosmerno? :rofl:

To nije dvosmerna komunikacija, a kad saljes request/response po istom principu, samo ne dobijes odgovor ODMAH nego je odgovor ODLOZEN (A PRINCIP JE ISTI), to po tebi jeste dvosmerna komunikacija? Objasni mi to molim te, kojom logikom.

Znaci ako dva coveka imaju po stap, ako ovaj prvi bocne drugog a drugi bocne prvog ODMAH - to po tebi nije dvosmerna komunikacija. Ali ako prvi bocne drugog a drugi saceka neko vreme pa bocne pvog - to po tebi jeste dvosmerna komunikacija? :sweat_smile:

Dakle, objasni mi koja je razlika izmedju tvog sistema i obicnog ajax short pollinga gde saljes request svakih X sekundi i dobijas odgovor od servera? Razlika je ISKLJUCIVO i JEDINO u tome sto je kod tebe odgovor servera odlozen i nista drugo… A onda prouci malo Websockets po uporedi koje su razlike i bice ti jasnije o cemu pricam.

Poenta price je da dvosmerna komunikacija u programiranju znaci da server moze da posalje REQUEST klijentu bez da je klijent to trazio i da klijent moze da posalje REQUEST serveru, bez da je server to trazio. A tvoj sistem ne funkcionise na taj nacin, eto to je cela poenta moje price. I uporno tvrdis da Websockets radi na istom principu - sto implicira da nemas pojma o cemu pricas i da nemas mnogo iskustva. Websockets samo kod prvog handshake radi na istom principu, nakon sto je otvorena linija NE RADI na istom principu kao tvoj sistem koji mora da salje novi request svaki put i da radi TLS handshake sto je najskuplja operacija u HTTP requestu…

Nije tesko izguglati i kroz sliku videti razliku, kako bi i laik mogao da vidi o cemu se ovde prica (ne znam da li si uplatio pro verziju chat gpt, kako bi mogao da pitas za sliku da bi ti bilo jasnije):


I slika obicnog HTTP request-a (koji je u sustini isto kao i long polling)

Mozemo da se gadjamo izrazima ovde do sutra, ali znam da razumes o cemu pricam. Sad si dodao KONTINUIRANA na izraz, kako bi tvoja prica imala nekog smisla, sto mi govori da neces da vodis konstruktivnu polemiku nego da teras neku svoju pricu, koja ne pije vodu.

Ispadas bezobrazan sa ovim poslednjim odgovorom i skrinsotom sto kacis, gde hoces da predstavis ljudima koji su neupuceni kako si ti pametan a ja ne mogu da razumem nesto sto je mnogo prosto… A jasno se vidi na skrinsotu da dodajes opet rec KONTINUIARANA kako tebi odgovara, kako bi AI dao odgovor koji ti zelis ovde ljudima da prikazes, zarad nekih simpatija ili cega god. Znaci manipulises i baratas polu informacijama, kako bi ispao pametan, a cinjenice ti nedostaju.

Pretvaras sve u neko filozofiranje, nisam imao nameru da se svadjam ili bilo sta, samo me je zainteresovala ova recenica, pa sam usao da vidim o cemu se radi:

ako nekoga bude zanimalo kako sam ovo izveo s obzirom da PHP uopće nema mogućnost asinkronog izvršavanja procesa. (Ili ipak ima? :grinning:)

Da bih shvatio da se ne radi ni o cemu zanimljivom nego o long pollingu koji ljudi koriste 30 godina, zato sam i odgovorio. Izvini sto sam se uopste upustao u ovu diskusiju… Najiskrenija sam hteo da skrenem paznju da se manes izmisljanja tople vode i predstavljanjem toga kao nesto WOW.

Nisam dodao da tjeram mlin na svoju vodu, nego zato jer sam poprilično siguran da oboje na to mislimo kada govorimo dvosmjerna komunikacija. Pa sam samo precizirao izraz da znamo što očekujemo i ti i ja kada kažemo riječ “dvosmjerna komunikacija”

Jer pazi, ako ne sporazumjevamo “dvosmjerna komunikacija” pod “dvosmjerna kontinuirana komunikacija”, onda zaista jeste svaki ajax dvosmjerna komunikacija, jer je signal išao u oba smjera. Clijent pita, server odgovara.

Znači ja i ti, kada kažemo “dvosmjerna komunikacija”, sporazumjevamo da se to odnosi na kontinuiranu dvosmjernu komunikaciju. Te smo složni oko toga ako sustav ne može postići kontinuiranu dvosmjernu komunikaciju, da ćemo reći jednostavnije “on ne omogućava dvosmjernu komunikaciju”

I ja i ti se onda slažemo da http request nije dvosmjerna komunikacija.
I ja i ti se onda slažemo da ajax nije dvosmjerna komunikacija.
Ali se ne slažemo oko Pulse sistema.

P.S. ajax request ne samo da nije dvosmjerna kontinuirana komunikacija, nego nije niti dvosmjerna komunikacija, jer samo jedna strana može pitati, dok druga strana može samo odgovoriti. (Dok Pulse osigurava da obje strane mogu postaviti pitanje)

Uglavnom, nisam baš niti malo išao na svoj mlin sa riječju “kontinuirana”, nego sam još otežao zahtjev što sustav mora ispunjavati da bi prihvatili da on omogućava dvosmjernu komunikaciju.

I nema nikakve potrebe za riječju kontinuirana (samo sam išao biti precizniji u izrazu), pa čitaj moj zadnji post isponova bez te riječi. Sve sam ti već objasnio što si sada opet pitao.

Žao mi je što sam ispao bezobrazan, ali meni je isto tako bezobrazno tvoje ignoriranje što znači riječ “dvosmjerna komunikacija”.

Ajmo po osnove, značenje riječi komunikacija:

Komunikacija je proces razmjene informacija preko dogovorenog sistema znakova, odnosno proces slanja informacija sebi ili bilo kojem drugom entitetu, najčešće putem jezika. Riječ komunikacija doslovno znači: podijeliti, učiniti nešto općim ili zajedničkim.

A sada dvosmjerna komunikacija:

Dvosmjerna komunikacija odnosi se na proces razmjene informacija između dvije strane, gdje obje strane imaju ulogu i pošiljatelja i primatelja poruka.

Vidimo i iz ovoga da ajax request ne ispunjava uvjet definicije dvosmjerne komunikacije jer ne mogu obje strane zauzeti ulogu onoga tko postavlja pitanje. (server može samo odgovarati)

Za Http request vrijedi isto.

Dok kod Pulse-a nije tako. Sistem pulse implementirajući svoju logiku upravo omogućava da u bilo kojem trenutku bilo koja strana može postaviti pitanje, time ispunjava uvjet definicije “dvosmjerna komunikacija”.

Zar ti nisam to objasnio već u prethodnom postu i sada opet.

Znači Pulse nakon inicijalnog poziva (a inicijalni poziv moraš imati i kod websocketa),… osigurava da uvijek ima otvoren barem jedan ajax request na serveru.
Time omogućava da server u bilo kojem trenutku pošalje poruku klijentu, isto kao što je omogućeno da u bilo kojem trenutku client pošalje poruku serveru.
Znači mogu obje strane u bilo kojem trenutku poslati poruku, i to onda jeste dvosmjerna komunikacija.

Ako bi imao sistem koji u sebi implementira takvu logiku da client šalje svake sekunde (prazan) ajax request (short polling), samo da provjeri jel server imao neko pitanje za klijenta … pa da, takav sistem bi isto omogućio dvosmjernu komunikaciju, ali sa očitim nedostacima. Nedostaci takve dvosmjerne komunikacije bi bili:

  • latencija: kašnjenje pitanja servera do max 1 sekundu
  • skupa bi bila: request mora ići svake sekunde (i kada nemamo informaciju svake sekunde). Ako bi kompenzirali ovaj nedostatak uvođenjem većeg delay-a, onda bi povećali latenciju, tj. pitanja servera bi više kasnila.

Znači dobiješ sistem koji omogućava tok informacije u oba smjera, omogućava da obje strane postavljaju pitanje, ali isto imaš vrlo nezgodne nedostatke takve komunikacije.

Dok Pulse sistem u potpunosti eliminira te nedostatke, jer bez ikakve latencije obje strane mogu poslati poruku u bilo kojem trenutku. A nemaš niti tu cijenu, jer putuje samo jedan request za jednu poruku.

Ove slike što si gore stavio, ti opet stavljaš sliku usporedbe Long Pollinga i Websocketa, ali uporno zaboravljaš da Pulse ne djeli karakteristike jednog Long Pollinga, jer je on sloj iznad koji koristi kombinaciju Long Pollinga upravo da dobije karakteristiku koju si okačio kao sliku za websocket.

Krivo, Pulse upravo omogućava to što si opisao.
(I džabe uvodiš riječ “u programiranju”, jer zna se što znači riječ dvosmjerna komunikacija, te ima isto značenje i u programiranju i izvan njega. Kao što vidiš, tvoja ovdje definicija se apsolutno poklapa sa definicijom te riječi koju sam stavio gore.)

Mislim da je sasvim ispravan način da ustvrdimo dali nešto omogućava dvosmjernu komunikaciju, da taj sistem promatramo izvana kao blackbox i ispitujemo ga.
Taj sitem ima dva ulaza, koji su istovremeno i dva izalaza. Točke A i B.

Kada pošaljemo signal na točku A, očekujemo da nam taj signal stiže na točku B.
Isto tako ako pošaljemo signal na točku B, očekujemo da nam taj signal stiže na točku A.

Ako su ta dva uvjeta ispunjena, možemo slobodno zaključiti da taj blackbox omogućava dvosmjernu komunikaciju između točki A i B. To je znači preduvjet dvosmjerne komunikacije.

Sasvim nebitno je jel u toj crnoj kutiji websocket ili sistem koji implementira periodične ajax short polling requestove ili nešto nalik kao Pulse. Može biti unutra i čimpanza sa štapom koja prenosi signal, ako to radi dosljedno imamo dvosmjernu komunikaciju.

No našim ispitivanjem ćemo također moći ustvrditi:

  • latencija: koliko je kašnjenje prijenosa signala
  • protočnost: kako se sistem ponaša pod velikim opterećenjem (puno paralelnih requestova)
  • stabilnost: dali sistem pravi grešku (čimpanza ostavi štap dok jede bananu i ponekada očekivani output ne detektiramo)

Pa kada bi tako ispitao crne kutije u kojoj je websocket i u kojoj je Pulse, dobio bi poprilčno slične karakteristike. (Iako ne tvrdim da bi tu Pulse zadovoljio karakteristikama kao websocket, ali bi definitivno prošao preduvjet dvosmjerne komunikacije i imao sasvim solidan rezultat.)

A kada bi tako ispitao ovaj tvoj sistem…

Dobio bi također ispunjene preduvjete za dvosmjernu komunikaciju, ali bi mjerio veliku latenciju.
Također ako bi mogao mjeriti koliko ta crna kutija troši resursa, onda bi mjerio da takva crna kutija je puno veći potrošač nego ona koja u sebi sadrži websocket ili Pulse.
Ako bi ta crna kutija imala neka podešavanja, onda bi također mjerio da što više tim podešavanjem smanjuješ latenciju, da ti ta crna kutija postaje veći žderač resursa.
Što se tiče protočnosti ovakvog sistema, sve zavisi kako bi bile rješene neke stvari unutra. Ako bi išla jedna poruka po tom jednom requestu, onda bi protočnost bila užasna, tj. latencija bi masu rasla pod opterećenjem sustava.
No ako bi server grupirao poruke i slao ih sve u jednom paketu prvom prilikom koja naiđe, onda veliko opterećenje nebi podizalo latenciju, ali kako je latencija već u startu slaba karika … nebi valjalo kako god okreneš.

Rekao bih da tvoja konfuzija u ovoj temi dolazi iz toga što se ne možeš dislocirati od onoga što se dešava u crnoj kutiji iz pukog razloga poznavanja materije što se zbiva unutra.

No pojedinačni proces koji se zbiva u kutiji, nije ekvivalent onome što ta kutija omogućava.

Tako bi mogao i razgovor mobitela secirati na njegove subprocese i tvrditi da neki pojedinačni signal koji putuje kao radio signal, da on ne omogućava dvosmjernu komunikaciju. Ali mobitel kao uređaj, koji implementira puno takvih pojedinačnih signala, on dakako omogućava dvosmjernu komunikaciju.
I opet, ako ga gledamo kao crnu kutiju, možemo mjeriti latenciju razgovora i sve ostalo…i time zapravo ustvrditi koliko je dobro ili loše ono što se dešava unutra.

Ti i dalje ne kapiras da u tvom sistemu server NE MOZE da posalje request bez da je klijent to pre uradio… Uporno govoris da je isti princip a nije, ne znam da li stvarno ne razumes ili jednostavno neces da razumes. Server u tvom slucaju ODGOVARA na request koji je klijent poslao i svaki ali svaki put KLIJENT mora da posalje request kako bi server odgovorio, samo sto je REQUEST odlozen i to je to.

Ja ne pricam ovde o prividnim stvarima i kakav osecaj krajnji korisnik ima, normalno da krajni korisnik nema pojma sta je u pozadini i da mu izgleda sve da je tako kao sto ti pricas. Ja pricam o onome sto je ispod haube, ako hoces da pricamo o tome, a ne o prividnim stvarima.

Jednostavno je jako, klijent mora da posalje request svaki put, kad server odgovori posle 5 sekundi ili 5 minuta, nebitno je, ti moras u pozadini da posaljes novi request nakon odgovora, Websocket ne mora - jednom se otvara konekcija i to je to, a kod tebe nije to slucaj.

Znači Pulse nakon inicijalnog poziva (a inicijalni poziv moraš imati i kod websocketa),… osigurava da uvijek ima otvoren barem jedan ajax request na serveru.
Time omogućava da server u bilo kojem trenutku pošalje poruku klijentu, isto kao što je omogućeno da u bilo kojem trenutku client pošalje poruku serveru.
Znači mogu obje strane u bilo kojem trenutku poslati poruku, i to onda jeste dvosmjerna komunikacija.

Evo ovde si sve objasnio, ko salje ajax request? Server??
Server samo odgovara na request, moras da pratis redosled radnji, znaci klijent uvek prvi salje request na koji server odgovara - i to je jedini tacan redosled. To sto ti pricas da server u svakom trenutnku moze da prosledi informacije, to je tacno ali moze da prosledi informacije samo zato sto je KLIJENT pre toga zahtevao te informacije…

Jako je prosto, vrtimo se oko iste stvari, ne mogu vise da se objasnjavam. Jednostavno postavi ovo na neki dev forum, pa ce ti ljudi objasniti isto, posto ocigledno nisam sposoban da ti docaram stvari ili razumes sve a vrtis svoju pricu iz nekog razloga…

Ja sam još pre dva dana rekla da je ovo simulacija dvosmerne komunikacije i evo sada ću da objasnim zbog čega nije prava dvosmerna komunikacija već simulacija.

Ovde klijent mora prvi da pošalje upit, pa server čeka i kada ima odgovor on ga isporuči klijentu. Nakon toga se komunikacija prekida i klijent mora ponovo da pošalje novi upit i da čeka odgovor.

Kod Websocketa klijent pošalje upit, server mu odgovori, ali se komunikacija ne prekida već ostaje otvorena, pa onda server može da pošalje nešto klijentu bez da je klijent poslao novi upit.

I evo sada figurativno objašnjenje kao što vas dvojica volite. Imamo Peru i Miku, Pera je u ovom slučaju server, a Mika je klijent.

LongPolling:
Mika zove mobilnim i pita Halo Pero šta ima
Pera se javlja i odgovara mu evo nema ništa.
Nakon ovoga veza se prekida, pa da bi Mika ponovo nešto pitao Peru mora opet da ga pozove na mobilni.

Kod WebSocketa:
Mika zove Peru Mobilnim i pita Halo Pero šta ima
Pera se javlje i odgovara mu evo nema ništa.
Ali sada se veza ne prekida već ostaje otvorena pa Pera može nešto da pita Miku, bez da Mika njemu postavi pitanje.Miko, a šta ima kod tebe?

Dakle glavni razlozi zbog kojih ovo nije prava dvosmerna komunikacija, su ti što kod longpollinga server ne može da šalje klijentu podatke, bez da je klijent nije pre toga poslao zahtev i zato što se komunikacija stalno prekida, dok je kod WebSocketa komunikacija stalno otvorena i server može da šalje neke informacije, bez da klijent pre toga pošalje zahtev ili upit.

Dakle u slučaju Longpollinga nema prave dvostruke komunikacije jer Pera nema pravo da postavi pitanje, već može samo da odgovara na pitanja Mike. Dakle komunikacija ide samo u jednom smeru prema Miki. Mika može i da pita i da dobije odgovor, a Pera može samo da daje odgovor, ali nema mogućnost da pita.

Sa tehničke strane Brus Li je u pravu, ali Bozoou je i dalje napravio dobru stvar, rešio puno problema i to u okruženju bez mnogo alata.

Ok, ajmo ovako…

  1. Slažeš li se samnom da bi ustvrdili dali neki uređaj omogućava dvosmjernu komunikaciju, da je dovoljno da taj uređaj promatramo izvana (kao blackbox) i da mjerimo dali prosljeđuje poruke sa točke A na točku B, isto kao sa točke B na točku A? Gdje se nakon inicijalne uspostave veze, signal mora moći prosljeđivati u oba smjera bez da to druga strana zahtjeva.

Što sve pri tome trebamo izmjeriti da bi što kvalitetnije mogli predstaviti karakteristike tog uređaja u njegovoj svrsi prijenosa informacije?

Hehe, opet brkaš sloj ispod sa slojem iznad.

Kada imaš Pulse, onda se klijent više ne spaja direktno na server sa ajaxom, nego se on spaja na kanal komunikacije preko Pulse sistema. I briga ga je što je ispod.

A na toj razini ne mora svaki puta zahtjevati da server pošalje poruku, nego je dovoljno da samo jednom inicijalizira razgovor, tj. nazove server na način:

var kanal = new Pulse();

Nakon te inicijalne konekcije on na tom kanalu prima poruku poruku kada je god server pošalje, isto kao što šalje poruku kada god to poželi. Ne mora ništa da zahtjeva.

Ispod haube, da… mora putovati jedan request po jednoj poruci i uvijek kreće prvo sa client strane.

No ja ti govorim o karakteristikama Pulse-a, a na toj razini više nema potrebe da se pitanja servera zahtjevaju.

Btw. što ti misliš koliko još slojeva ima ispod websocketa, da se to sve rasčlani do razine frekvencije struje, nebi li se ta frekvencija dekodirala i poruka poslagala u određene pakete … kad bi ti cijeli proces bio jasan do krajnje dubine, tamo gdje se neki elektron pobudio i preskočio iz jednog atoma u drugi, što bi ti uopće na toj razini značila riječ “dvosmjerna komunikacija”?
Bili i tada tvrdio da za dvosmjernu komunikaciju elektron mora moći istovremeno iskakati iz atoma i uskakati u njega?
Ili bi možda shvatio da i ta tvoja dvosmjerna komunikacija je na razini ispod ipak rasčlanjena na nekakve sinkrone procese koji ju omogućavaju da postoji na razini sustava iznad.

Već sam ti to objasnio i sa primjerom mobitela.

Zato nije ispravno secirati sistem na dijelove i prosuđivati ga po izoliranim komponentama… ispravno ga je sagledati u cjelosti i kao takvog protumačiti njegovu funkciju i njegovu karakteristiku ponašanja… i na toj razini zaključiti omogućava li taj uređaj dvosmjernu komunikaciju ili ne, što je očito da Pulse omogućava.

Pazi ovo, po tvome ako ti ja dam tri telefonska uređaja … i ti nakon što se uvjeriš da sa svakim od tih uređaja možeš nekoga nazvati i razgovarati s njim i ja te onda pitam: “Da li ti uređaji omogućavaju dvosmjernu komunikaciju?”

Tvoj odgovor bi znači bio: “Ne znam, jer ne znam što je ispod haube tih uređaja”

Koliko je to smješno i besmisleno, ne znam šta da ti kažem.

Po tom tvome onda ništa ne znamo o ničemu, jer svaka komponenta ima ispod haube nešto i tako beskonačno u dubinu, i mi nikada nebi mogli ništa sagledati do kraja.

I ne znamo ništa do kraja, ali zato postoje ispitivanja da nešto ispitamo i provjerimo kako se ponaša u domeni koja je za nas relevantna. Ja vidiš kad uzmem telefon u ruke, nazovem nekoga i s njime popričam… zaključim “Da, ovaj telefon mi omogućava dvosmjernu komunikaciju”.

Kad sam uzeo ajax u ruke, zaključio sam da mi on to ne omogućava. Zato i jesam napravio Pulse, koji mi sada omogućava dvosmjernu komunikaciju sa serverom.

Riječi su tako jednostavne, ne znam zašto praviš od njih nešto što nisu.

Ti pricas o svemu mnogo povrsno, kao da se nista ne zna, nego smo u 1990 i internet se tek izmislja. Cas ides u sitne detalje, a cas hoces da mi kazes pravi se da ne znas ispod haube i ne pitaj na koji nacin funkcionise. Ja ovde pricam upravo sta je ispod haube, i zna se kako funkcionise Websocket, nema tu nekih tajni kao sto pricas. Prosto je i jednostavno, imas razlicite protokole na webu, preko kojih se komunikacija odvija. Svaki protokol ima neke karakteristike, i ima razlog zasto se koristi. Websocket koristi TCP protokol, a tvoj sistem HTTP protokol. U tome i jeste glavna razlika, TCP protokol omogucava po prirodi dvosmernu komunikaciju a HTTP protkol NE OMOGUCAVA. I tu se prica zavrsava, ne znam sta ti tu nije tacno jasno? Ti uporno teras svoju pricu i pricas kako si ti napravio dvosmernu komunikaciju pomocu sistema koji koristi HTTP protokol, a kada te neko pita kako, tvoj odgovor je pravimo se da ne znamo sta je ispod haube. Vredjas mi mozdane celije svojim odgovorima…

Konsultuj se sa svojim virtuelnim prijateljem, posto ovako mozemo u krug do sutra :slight_smile:

1 Like

Pa ako sistem bilježi karakteristike dvosmjerne komunikacije, onda se ti slobodno zapitaj kako i što je ispod haube … ali nemoj da pretpostavljaš ako su ispod haube elementi koji nativno ne pružaju dvosmjernu komunikaciju, da pomoću njih ista nije izvedena.

Puno stvari u prirodi nativno nešto ne pruža, ali ako se iskombinira na određeni način, onda se postigne to što oni nativno ne pružaju.

Jesi li ti znao da bezmotorna jedrilica može ploviti uz vjetar?
Pa kako, pa kako to??.. kad je jedro element koji nativno ide samo niz vjetar.

Ti kad bi i izmjerio kako jedrilica pomoću jedra ide uz vjetar, rekao bi da to nije plovidba uz vjetar jer ona koristi isključivo jedro koje je element da ide niz vjetar, hehe.

Tako se točno ovdje ponašaš. Iako mjerimo na uređaju dvosmjernu komunikaciju, tvoja tvrdnja je da to nije dvosmjerna komunikacija, jer eto sistem je napravljen od elemenata koji istu nativno ne podržavaju.

Pa bemu bigulicu, da je nativno podržavaju onda bi sa time bilo lagano napraviti Pulse, par linija codea bi bilo… i nebi bilo vrijedno spomena.

Nego ajde budi frajer pa komentiraj ovo:

Znam ja dobro što je ispod haube, ali ti očito ne možeš shvatiti da karakteristika nekog sistema nije ekvivalent karakteristici neke pojedine komponente ispod haube od koje je taj sistem napravljen.

I s obzirom na tu činjenicu, morao bi moći prihvatiti da karaktristika Pulse komunikatora je točno onakva kakvu isti postiže. (A to je dvosmjerna komunikacija sa vrlo malom latencijom)

I dok ju postiže, ta karakteristika je istinita, činjenična… a ne nešto prividno. (Kako si se izrazio da je Pulse prividna stvar)

Btw. Sa zadnjim updejtom na kojem radim, vjerujem da ću imati karakteristiku protočnosti informacije čak bolju nego sa nativnim websocketom, pa si ti misli kako.

Mnogo filozofiraš brate, neću da pričam o telefonskim uređajima, o ljudima koji se bockaju štapovima itd :grin: Postavio si package koji si napravio u PHP-u i o tome hoću da govorim, a ti uporno porediš sa nekim trivijalnim stvarima jer nemaš direktne argumente ni za šta. Postavi lepo ceo kod na Github, pa ćemo da polemišemo koliko hoćeš.

Btw. Sa zadnjim updejtom na kojem radim, vjerujem da ću imati karakteristiku protočnosti informacije čak bolju nego sa nativnim websocketom, pa si ti misli kako.

Ove tvrdnje su u rangu malog deteta koje se naljutilo… Ako ti je poenta bila da okačiš nešto i da ti mi verujemo na reč da je to tako, bez da nam objasniš na koji način si došao do toga onda okej. Ja bih voleo da naučim nešto novo i da mi objasniš kako si došao do nečega i da pričaš direktno o tome, a ne da mi vrtiš neke priče iz života koje nemaju veze sa ovim i da mi na kraju kažeš da se ja mislim kako :slightly_smiling_face:

Znao sam da nećeš odgovoriti. Ne možeš jer si nisi dosljedan. A to znači da barataš lažnim tvrdnjama.

Ti bi bio odlican politicar, to je jedino sigurno :slight_smile: Na sta da ti odgovorim? Na teoriju o telefonskim uredjajima ili na kako bezmotorne jedrilive plove uz vetar? Ne znam nisam moreplovac na zalost…

2 Likeova

Zar ni pitanje ne znaš pročitati?

Pitam chatGPT:

Hej, imam diskusiju sa jednim čovjekom koji ne priznaje da jedna moja komponenta omogućava dvosmjernu komunikaciju, iako ona očito i mjerljivo omogućava razmjenu poruka u oba smjera. Moja komponenta je izgrađena u tehnologijama Javascript i Php i koristi u backgroundu ajax koji sam po sebi ne omogućava dvosmjernu komunikaciju. Ali moja komponenta kombinira ajax na takav način da omogućava da server u bilo kojem trenutku posalje poruku klijentu i obrnuto.

Čak i kada nebi znali što je u komponenti ispod haube, nije li dovoljno izmjeriti karakteristiku ponašanja komponente da zajljučimo omogućava li ona dvosmjernu komunikaciju?

Ona odgovara:

Apsolutno, mjerenje karakteristika ponašanja komponente može biti dovoljan pokazatelj za donošenje zaključka o njenoj sposobnosti dvosmjerne komunikacije, bez obzira na tehnologiju koja je koristi “ispod haube”.

U ovom slučaju, bitno je razlikovati tehnologiju koja omogućava osnovne funkcionalnosti (kao što je AJAX, koji je inherentno jednosmjeran) od apstrakcije ili komponente koju si izgradio na temelju te tehnologije. Ako tvoja komponenta omogućava slanje i primanje poruka između klijenta i servera bez da korisnik mora ručno inicirati zahtjeve u oba smjera, onda ona pruža funkcionalnost dvosmjerne komunikacije, bez obzira na to kako je ta funkcionalnost tehnički ostvarena.

U diskusiji možeš koristiti sljedeće argumente:

  1. Praktično ponašanje: Ako komponenta omogućava da server inicira slanje poruke klijentu (npr. putem dugotrajnih AJAX veza, periodičnih pingova ili polling strategija), to je dvosmjerna komunikacija jer podaci teku u oba smjera.

  2. Funkcionalni dokaz: Dvosmjernost je funkcionalni aspekt — ako možeš demonstrirati da server šalje poruku klijentu i klijent odgovara (ili obrnuto), dokazao si njen kapacitet za dvosmjernu komunikaciju.

  3. Odvojenost implementacije i funkcionalnosti: Kako je komponenta implementirana (npr. korištenjem AJAX-a ili nečeg drugog) ne mijenja činjenicu da ona pruža dvosmjernu komunikaciju. Ovo je slično načelu da korisnika aplikacije zanima funkcionalnost, a ne detalji implementacije.

Dobar primjer bi bio da usporediš tvoju komponentu sa WebSocket-om — iako WebSocket nativno podržava dvosmjernu komunikaciju, krajnji rezultat tvojeg rješenja (kombiniranjem AJAX-a) može pružiti isti efekt. Stoga nije presudno kakva je tehnologija korištena, već što krajnji proizvod omogućava.

Predloži da se testira komponenta u stvarnom scenariju, gdje se mjeri ponašanje i karakteristike komunikacije, kako bi se razriješila diskusija na objektivan način.

Stvarno smo došli u vrijeme da su računala pametnija od ljudi. Sorry, ali ovo je toliko pametniji odgovor od svega što si napisao u ovoj temi. Primjeti kako je elaborirala po svim točkama koje ti uporno pokušavam objasniti… koje ti ne možeš shvatiti niti kad ti se nacrta, a ona ih sama dokuči.

Sve je lijepo iznjela, samo što ti kada bi i vidio glavni dokaz koji je praktično ponašanje komponente (mogućnost razmjene poruka) ti i dalje nebi priznao da je to dvosmjerna komunikacija jer si si to tako utupio u glavu iz neosnovanih razloga.

A baš je dobro objasnila. (Iako sam ti sve to već i ja objasnio. Više puta.)

Čitam već dva dana šta pišete ti i Brusl Li. Ti si napravio lepu stvar, ali sada već pokušavaš da odbraniš nešto neodbranjivo. Šta god da kaže Chat Gpt nije u pravu i vidim da se Chat baš nalupetao gluposti.

Sa tehničke i programerske strane Bruce Lee je potpuno u pravu, Pulse nije prava dvosmerna komunikacija. Sa funkcionalne strane možemo reći da simulira dvosmernu komunikaciju.

Takođe ti pokušavaš da ga uporediš sa mobilnim telefonima i kažeš da ako svaki mobilni uređaj može da pozove i da drugi odgovori to je onda dvosmenra komunikacija. Ali mobilni uređaji i Pulse se ne mogu porediti, zato jer kod Pulsea server ne može prvi da pozove klijenta. Dakle ako imamo mobilni A koji je server i mobilni B koji je klijent, B bi uvek mogao da pozove A, takođe A bi mogao da mu odgovori, ali A nikada ne bi mogao da pozove B. Jasno je da sa tehničke strane to onda nije dvosmerna komunikacija.

Zamisli sada imaš ženu. I zabraniš joj da ti postavlja pitanja i onda kažeš evo ja i moja žena imamo zadravu dvosmernu komunikaciju. Ali to nije prava dvosmerna komunikacija već ona samo odgovara na tvoja pitanja. Dakle, tako je i sa Pulseom server može samo da odgovara na pitanja, ne može da šalje ili pita, zbog toga to nije dvosmerna komunikacija, već samo njena simulacija.

I za ovo nema šta da pitaš chat Gpt, ovo je osnovna stvar i već se odavno zna kako funkcioniše.

Sam sebe ukopavas i kotradiktoran si sam sebi… Vidis da tvoj prijatelj robot ti govori da je i short polling dvosmerna komunikacija, po tvom filozofoskom principu, a sad se vrati u tvoje prosle poruke gde uporno tvrdis kako short polling nije dvosmeran a tvoj Pulse sistem jeste (u vise navrata si ovo tvrdio). Jednostavno menjas misljenja kako tebi odgovara u datom trenutku, ja sam dosledan sebi i od pocetka tvrdim isto. Dakle, zakljucimo diskusiju - sve je dvosmerna komunikacija, zavisi samo kako je ko filozofski raspolozen :rofl: I da devojka te lepo gore savetovala da se manes Chat GPT, dobro je poznato da zna da lupa gluposti, pogtovo kad ga napinjes verovatno kao u tvom slucaju da vuce na tvoju vodenicu. Doslo vreme da se zenama lakse objasne stvari nego muskarcima :sweat_smile: sala :slight_smile:

Loš si u pamćenje, itekako sam dosljedan cijelo vrijeme i upravo sam rekao isto što i chatGPT.
Opet ne razlikuješ single ajax short polling od sistema koji bi implementirao frekventni short polling i tako omogućio dvosmjernu komunikaciju. Evo što sam rekao:

Ako bi imao sistem koji u sebi implementira takvu logiku da client šalje svake sekunde (prazan) ajax request (short polling), samo da provjeri jel server imao neko pitanje za klijenta … pa da, takav sistem bi isto omogućio dvosmjernu komunikaciju, ali sa očitim nedostacima. Nedostaci takve dvosmjerne komunikacije bi bili:

  • latencija: kašnjenje pitanja servera do max 1 sekundu
  • skupa bi bila: request mora ići svake sekunde (i kada nemamo informaciju svake sekunde). Ako bi kompenzirali ovaj nedostatak uvođenjem većeg delay-a, onda bi povećali latenciju, tj. pitanja servera bi više kasnila.

Znači dobiješ sistem koji omogućava tok informacije u oba smjera, omogućava da obje strane postavljaju pitanje, ali isto imaš vrlo nezgodne nedostatke takve komunikacije.

I nemoj molim te o dosljednosti, jedino si ti taj kojeg je tvoja logika ukopala da ne smiješ niti da odgovoriš jel mobilni uređaj omogućava dvosmjernu komunikaciju. :sweat_smile:

To smo već ustanovili, niti websocket ne može da prvi zove klijenta.

Po tome se istina mobilni uređaj razlikuje od websocketa i Pulsea, ali po tome se oni međusobno ne razlikuju.

Btw. Ja ne poređujem Pulse i mobitel.

I nisi odgovirila na pitanje:

Ne napinjem ga. Otvorio svježu temu, postavio jedno pitanje i proslijedio ovdje i pitanje i odgovor. Kopiraj pitanje i uvjeri se sam da nema dodatnog natezanja. :wink:

Drugi par čarapa je što očito nisi sposoban razumjeti taj odgovor iako je precizno elaboriran.

Fakat mi nije jasno koliko moraš biti ograničen svojim pretpostavkama i ne shvatiti da je objektivno ustvrđivanje dali uređaj omogućava dvosmjernu komunikaciju, jednostavno uzeti uređaj i testirati ga. Znači vidjeti jel on to u praksi omogućuva.

Ako to ustvrdiš, ta funkcionalnost sigurno postoji nezavisno od toga što je ispod haube implementirano da istu omogući.

Isto kao kada ustvrdiš da jedrilica plovi uz vjetar, to je neosporivo iako znamo da bi jedro nativno samo po sebi išlo isključivo niz vjetar.

Zato je filozofija ustvrdila:

Cjelina je veća od zbroja svojih djelova.