Studoši

Je li prije generiranja novog ocitanja cvor mora pricekati da primi potvrde za trenutno ?

laranotreallycroft da, ali blokira thread, što ne?
Imaš thread za slanje svog očitanja ostalim senzorima, kad pošalje paket s očitanjem, stvori novi thread koji čeka potvrdu (jesam dobro shvatio?), ali taj novi thread može zapeti beskonačno dugo ako se potvrda izgubila u mreži.
Metoda receive() nema nikakav timeout parametar, a po defaultu je na socketu postavljeno na inf (blokiranje bez timeouta).

RogerRoger ne ne, za svaku poruku koja se salje se stvara novi thread. Znaci pozovem ovaj StupidUDPClient kao novi thread i onda nek blokira sam sebe kolko hoce u vlastitom threadu. Isti je thread za slanje i cekanje odgovora na poslano.

laranotreallycroft u redu, tako sam i ja mislio napraviti, ali i dalje me buni ovo.
Ako želiš poslati očitanje, stvoriš jedan novi thread za server koji šalje to očitanje, on ga pošalje, čeka potvrdu jer je blokiran receive() metodom, ali potvrda se izgubila (realan slučaj jer je lossRate 30% po tekstu zadatka). U tom slučaju, on nikad ne dobije potvrdu, nema timeouta, a ako nije dobio potvrdu jer nije ni poslana, tj. zagubio se originalan paket, onda ni druga strana nikad ne dobije poslano očitanje. Kako dođe do retransmisije onda, ako je server cijelo vrijeme blokiran jer čeka potvrdu koja neće doći?

RogerRoger
Server je jedan odvojeni thread koji je zasebno pokrenut i koji slusa kaj mu dolazi i salje odgovore.
Klijent je zaseban thread i vise ih moze biti odjednom pokrenuto jer je to odvojeni thread koji ne blokira main thread koji stvara i salje nova ocitanja niti ne utjece na server thread. Takoder treba implementirat retransmisiju ako ne dobije odgovor, znaci osim ako je cvor koji salje ugasen,dobit ce odgovor prije il kasnije

laranotreallycroft hvala ti na objašnjenju, al ne kužim i gotovo. Razumijem što želiš reći sa serverom i klijentom, ali ne kužim kako ti radi za sljedeći scenarij: thread (server ili klijent, ovisi kako ga zoveš) pošalje paket, paket se izgubi u mreži, on čeka potvrdu metodom receive(), ne dobije ju jer paket nije primljen, kako on može pokrenuti retransmisiju ako je blokiran receiveom? Kako itko skuži da potvrda nije primljena?

RogerRoger Prva rečenica 5.6 poglavlja:
“Ako čvor ne primi potvrdu za poslani podatkovni promet, ponovno šalje taj podatknovni promet.”

RogerRoger
Imaš thread koji sluša za incoming poruke i thread koji šalje poruke. Ovaj koji sluša dolazeće ce ack poruku staviti u necki blocking queue koji ce probuditi thread koji je poslao. Thread koji je poslao i ceka ack radi poll na taj blocking queue.

Googlaj malo i pretrazi na gitlabu DZ sa java vjestine ili sa OPRPP2 predmeta bio je za zadacu chat UDP server i klijent na kojem je trebalo rjesiti istu problematiku.

in1 okej, nisam debil, kužim to
Ali ako ju očekuje, očekuje ju koristeći receive, jel da
A ako ju ne dobije, ostaje blokiran jer je receive blokirajuć, a socket klasa koju su nam dali je namještena da nema timeout
I što onda, voditi neki dictionary u glavnom programu i samo otvarati novi thread za svaki koji ne primi potvrdu?

WickyWinslow gdje se može pronaći taj dio sa predmeta OPRPP2, koliko vidim na materijalima nema ništa?

Znači li to da zapravo mi koristimo u ovom labosu samo jedan socket jer vidim da su stavili napomenu da promet potvrda i očitanja treba ići preko samo jednog porta?

VelikiMarko Socket po nodeu/peeru, da.

Čemu su nam onda dali dva konstruktora za onaj SimpleSimulatedDatagramSocket? Jedan kao za klijentsku stranu, a drugi za serversku.

kako vi inkrementirate vektore ?
jel samo sa slanjem/primanjem ocitanja, ili se tu racuna retransmisija i potvrda ?
i na kako bi trebao sortirati ocitanja po vektorima, to mi uopce nije jasno

isto ne kuzim kako bi trebali implementirat mijenjanje skalarnog vremena
ako mi trenutno vrijeme dohvacamo sa currentTimeMillis() i recimo da je to vrijeme 3 npr, a vrijeme od primljenog paketa je 4, kako cemo mi sad promijenit vrijeme 1. senzora na 5 ?
jer ako ne promijenimo, moze se desit da sljedece ocitanje od 1. senzora bude ocitano u vremenu 4 zbog currentTimeMillis jer ga nismo promijenili

Erpeg ja sam to implementirao tako da imam fju update() koja prima vrijednost sata i racuna razliku izmedu te nove vrijednosti i this.currentTimeMillis() i onda tu razliku (ako je pozitivna) sprema u privatnu varijablu. Vrijednost te varijable sam samo zbrojio na kraj returna od currentTimeMillis().

dobivam ovo kad pokrećem zookeeper u cmd-u u 3.3? kako se to rješava?
The input line is too long.
The syntax of the command is incorrect.

sphera
kafka ne voli duge putanje pa stavite na neke kratke putanje kao u uputi C:\kafka..., druga stvar je da ako ne može nać putanju, ’can’t find path specified’ onda možda imate razmake u putanji java_home-a ili je ta putanja invalidna pa se pobrinite da je validna

Kako spojiti vise consumera na kordinator, meni jedan uhvati poruku a drugi ne, isto mi se dogodi s njihovim primjerom kafke s ferneta kad pokrecem dva consumer procesa i jedan producer proces…

Dima To ti se događa jer kafka za istu grupu stvara particije i procesi unutar iste grupe ne mogu čitati iste poruke nego svaki dobije svoj “set”, trebaš za groupid stavit UUID.randomUUID().toString() tako da ti svaki Consumer bude u novoj grupi

Dima
stavi ovo prije .poll ->
<tvoj_consumer>.seekToBeginning(<tvoj_consumer>.assignment());
i ovo nakon neke petlje u kojoj citas ->
consumer.commitAsync();
onda ce ti svi consumeri citati sve poruke

Može li mi netko pls objasniti (ili me uputiti na neko objašnjenje) kako sortirati poruke prema vektorskim oznakama?
Za skalarne mi je naravno intuitivno jer su brojevi, ali vektorske su (kako sam ja to shvatio) skup skalarnih za svakog sudionika. Kojim principom to sortirati?

RogerRoger

recimo da sortiras ocitanja u senzoru 1 i imas ova 3 (u crvenom kvadratu)
prvo ocitanje je taj senzor generirao i njegova oznaka je 3
drugo ocitanje koje je primljeno ima dolazi sa vektorom (1,4,3). ti od toga uzimas oznaku za prvi senzor (1) i gledas jel ta oznaka veca il manja od oznake u generiranom ocitanju.
u ovom slucaju oznaka 1 je manja od 3, iako je ocitanje generirano kasnije. senzor 1 misli da je ocitanje generirano ranije (zbog oznake) i stavit ce ga prvog u listu.
sljedece ocitanje koje mora sortirat je sa vektorom (3,6,5).
to ocitanje ima istu vrijednost (oznaceno plavom) kao i vrijednost senzora 1 (3), pa ces to stavit nakon vlastito generiranog ocitanja.

nadam se da ti je jasno sad, ja sam se isto borio da shvatim sve to