Socket.io-php- socket id disconnect

Socket.io-php- socket id disconnect
2019-12-30T20:37:20+01:00
2020-01-02T22:51:15+01:00
2022-10-15T21:16:23+02:00
mittnik
sziasztok.

PHP(html)-Socket.io -NodeJs- kombóval kisérletezek.

A feladat hogy kliens csatlakozzon a szerverre, eddig ok. Ha a kliens elnavigál egy linkek keresztül, akkor természetesen socket disconnect van.

Azt szeretném ha a socket nem szakadna meg, ezt úgy oldottam meg hogy az index.php-ben csináltam egy iframe -et, amibe betöltöm a linkelt oldalakat. de valamiért a socket így is megszakad, az index.php-be tettem a socket.io scriptet és definiáltam a kapcsolatot. Ha minden oldalra beteszem , akkor a nodeJS minden linkelésnél disconect-connect üzenetet dob.
vagyis él a kapcsolat, visztont nekem a socket-id-vel kell dolgoznom.

Hogy oldjam meg hogy a kapcsolat stabil legyen és ne kelljen minden oldalamra beraknom a socket  connect-et?

Köszi előre is
Mutasd a teljes hozzászólást!
VueJS..

Youtubeon van fent egy 40+ részes tutorial, 2 éves, relatív friss...
Nem reklámozom, VueJS tutorial címszó alatt megtalálod, ha keresed.

Azért tanácsolom ezt, hogy ne kelljen feltalálnod újra a spanyolviaszt.
Végül Jquery-vel is ott fogsz kikötni, hogy bizonyos response-ra/akármire bizonyos div-eket elrejtesz, másikat megjelenítesz.
Na ennek érdekében, hogy ne zavarodj össze és tépd ki az összes hajadat, használhatsz egy front-end frameworkot.

Ezek annyit tesznek csak többnyire, hogy ügyesen manipulálják neked a DOM-ot, elvesznek, hozzáadnak komponenseket, stb stb.

PHP meg nem kell ebbe a stackbe véleményem szerint.
PHP jó lehet, ha sima JSON adatokat akarsz visszaadni, htmlt renderelni,de ha szóbajön a realtime, akkor socket kelleni fog, az pedig socket.io-val a legegyszerűbb és nodejs-sel.
Ha meg már Nodejs-hez hozzányulsz, miért ne vinnéd az egészet oda? (express js)

Ha meg eljutottál odáig már, hogy megvan a frontend appod, a backendet is nodejsben tervezed, akkor csinálhatsz olyat, hogy a kliens socketen csak fogad, http-n meg küld. Nem tudom mennyire nyerő az ötlet, én kacsingatok felé a projektemhez.
A lényege, hogy üzenetküldésnél pl a küldésre egy http (POST) requestet küldesz az API-nak, az megkapja, feldolgozza és io objektel meg emittel vissza. Kliens megkapja a csomagot és kész.
A csomag tartalmazhat olyat, hogy sender_user_id, és ellenőrzöd, hogyha a kliens_id megegyezik sender_user_id-val, akkor ő küldte az üzenetet és így jársz el a továbbiakban...(pl neki nem küldesz notificationt, másnak igen)
Mutasd a teljes hozzászólást!

  • (Lehet a SPA(Single Page Application) a te barátod.)

    Különben, minden más URL-re navigálva, egy új http requestet küld a kliens a szerverednek, új választ(json/html) várva.

    Vagy nem navigálgatsz, hanem dinamikusan cserélgeted az oldalelemeket jquery-vel, vagy használsz egy frontend frameworkot.
    Mutasd a teljes hozzászólást!
  • Konkrétan milyen jquery megoldàsra gondolsz? Tudnàl példakódot vagy linket adni?
    Mutasd a teljes hozzászólást!
  • VueJS..

    Youtubeon van fent egy 40+ részes tutorial, 2 éves, relatív friss...
    Nem reklámozom, VueJS tutorial címszó alatt megtalálod, ha keresed.

    Azért tanácsolom ezt, hogy ne kelljen feltalálnod újra a spanyolviaszt.
    Végül Jquery-vel is ott fogsz kikötni, hogy bizonyos response-ra/akármire bizonyos div-eket elrejtesz, másikat megjelenítesz.
    Na ennek érdekében, hogy ne zavarodj össze és tépd ki az összes hajadat, használhatsz egy front-end frameworkot.

    Ezek annyit tesznek csak többnyire, hogy ügyesen manipulálják neked a DOM-ot, elvesznek, hozzáadnak komponenseket, stb stb.

    PHP meg nem kell ebbe a stackbe véleményem szerint.
    PHP jó lehet, ha sima JSON adatokat akarsz visszaadni, htmlt renderelni,de ha szóbajön a realtime, akkor socket kelleni fog, az pedig socket.io-val a legegyszerűbb és nodejs-sel.
    Ha meg már Nodejs-hez hozzányulsz, miért ne vinnéd az egészet oda? (express js)

    Ha meg eljutottál odáig már, hogy megvan a frontend appod, a backendet is nodejsben tervezed, akkor csinálhatsz olyat, hogy a kliens socketen csak fogad, http-n meg küld. Nem tudom mennyire nyerő az ötlet, én kacsingatok felé a projektemhez.
    A lényege, hogy üzenetküldésnél pl a küldésre egy http (POST) requestet küldesz az API-nak, az megkapja, feldolgozza és io objektel meg emittel vissza. Kliens megkapja a csomagot és kész.
    A csomag tartalmazhat olyat, hogy sender_user_id, és ellenőrzöd, hogyha a kliens_id megegyezik sender_user_id-val, akkor ő küldte az üzenetet és így jársz el a továbbiakban...(pl neki nem küldesz notificationt, másnak igen)
    Mutasd a teljes hozzászólást!
  • jQuery-nek esetleg a html függvénye kell, de azt könnyedén leprogramozod. Igazából a szemlélet rossz. Úgy kell csinálni, hogy nem navigálsz el az oldalról, csak cserélgeted a tartalmat. Akár ajaxosan, de ha már állandó kapcsolatban vagy a socketen keresztül, akkor akár azon keresztül is lekérdheted az új tartalmat.

    A socket.id nem kéne beazonosítsa a látogatót, a session/cookie elérhető socket használat mellett is. Így akárkit be tudsz azonosítani, akár órákkal később is, vagy akkor, ha megszakad valamiért a kapcsolat.
    Mutasd a teljes hozzászólást!
  • Service Workerrel, az osszes tobbi valasz szimplan hulyeseg.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd