ugrás a tartalomhoz

"éppen ír" hogyan célszerű

kriszrap · 2016. Május. 17. (K), 08.31
Kedves Weblaborosok.

Amikor a kliens ír:
Amikor a felhasználó elkezd gépelni onkeyup segítségével felküldöm az adatott adatbázisnak pl az idöpontot,elküldve.

Ezzel az a problémám minden leütéssel frissít nem lesz energia pazarló?? vagy ti hogy oldanátok meg??

amikor éppen ír akkor mindig váltosztatom az időt és elküldve rész marad
nulla(elküldve rész azért kell ha például megáll a felhasználó az írással).

A várakozó fél 5 másodpercenként kéri az infot
ha a dátum 5 másodpercenbelül van és még nincs elküldve akkor "éppen ír"
ezek nem valósulnak meg akkor "már nem ír".

Ti így oldanátok meg????
Segítséget előre köszönöm
‹ Szöveg megjelenítése adat átadás linkből jQuery-nek ›
 ■
1

Érdekes téma, remélem érkezik

firith · 2016. Május. 17. (K), 09.34
Érdekes téma, remélem érkezik rá majd válasz.

Amikor a felhasználó elkezd gépelni onkeyup segítségével felküldöm az adatott adatbázisnak pl az idöpontot,elküldve.


erre érdemes megnézni az underscorejs throttle és debounce függvényeit.
2

Ha már chatet csinalsz akkor

jgege · 2016. Május. 17. (K), 10.57
Ha már chatet csinalsz akkor jobb lenne websocketet hasznalni, ott erre elég egyértelmü a megoldás :)

php websocket lib pl
ratchet

Amit még tehetsz h nem minden keyupnal kuldod hanem varsz mondjuk fel mp-t...
3

Öhmmmm "websocketet" mire jó,

kriszrap · 2016. Május. 17. (K), 11.14
Öhmmmm
"websocketet" mire jó, mire való,Miért jobb???:)
4

WebSocket

Poetro · 2016. Május. 17. (K), 12.47
A WebSocket internetes technológia, ami kétirányú, duplex kommunikációs csatornák kiépítését teszi lehetővé egyetlen TCP socketen keresztül. Kifejlesztésének fő motivációja volt, hogy a webböngészőben futó alkalmazás képes legyen a szerverrel való kétirányú kommunikációra a Comet barkácsmegoldásai (több HTTP-kapcsolat nyitva tartása; XMLHttpRequest vagy <iframe> és long polling) nélkül, bizonyos esetekben a szükségtelen fejlécforgalom akár 500:1-1000:1 arányú, a késleltetés 3:1 arányú csökkentésével. Korlátozó tényező volt a HTTP 1.1 specifikációja, mely kimondja, hogy a böngészőnek legfeljebb két kapcsolatot szabad egyidejűleg nyitva tartani a webszerver felé. A WebSocketet megelőzően nem volt lehetséges komplexebb, a szerverrel valós idejű kommunikációt igénylő webes alkalmazást, pl. csevegő alkalmazások, árfolyamkijelzők, játékok, levelezőkliensek a HTTP-kapcsolat nem rendeltetésszerű használata nélkül megvalósítani.

Forrás: Wikipédia
5

Nagyon szépen köszönöm a

kriszrap · 2016. Május. 19. (Cs), 09.35
Nagyon szépen köszönöm a segítséget megláttom mire jutok:))
szerk.:
Annyit szeretnék még kérdezni hogy tudna nekem linkelni valaki egy oldat??:(((

Másik meg sikerült megoldanicsak websockettel nem foglalkoztam még(ajax használtam mindig is)
6

Részletesebben

Poetro · 2016. Május. 19. (Cs), 10.35
Az előző hozzászólásban linkeltem neked egy oldalt. Mit sikerült megoldani?
8

Linkek

vmarci21 · 2016. Május. 25. (Sze), 10.23
Lekérésekre lehetőségek
Node.js-es Websocket minta (Herokuapp dokumentáció, ott egyből, ingyen ki is lehet próbálni ;) )
7

Sikerült azt hogy onkeyup

kriszrap · 2016. Május. 19. (Cs), 20.54
Sikerült azt hogy onkeyup segítségével felküldöm az adatokat késleltettve és a másik fél 5 másodpercenként infot kér a szervertöl. (Ajax os frissitéssel)
Szerintem ez energia pazarló.
Ezért szeretném meg tanulni a websocketet.
9

Előre optimalizálás

Hidvégi Gábor · 2016. Május. 25. (Sze), 10.57
Ez valami megérzés, hogy energiapazarló, vagy pedig alá is tudod támasztani? A websocket meg nyitva hagy felhasználóként egy portot, aztán nagyobb terhelésnél csodálkozhatsz, ha nem tudnak többen csatlakozni.
10

Portot? Ezzel a problémával

BlaZe · 2016. Május. 25. (Sze), 11.10
Portot? Ezzel a problémával találkoztál élesben? Mi a felső limit? A folyamatos polling jobb terhelés szempontjából?
11

Socketre gondoltam, a felső

Hidvégi Gábor · 2016. Május. 25. (Sze), 13.07
Socketre gondoltam, a felső limit pedig az operációs rendszertől és szoftverkörnyezettől függ. Hogy melyik technikát érdemes választani, függ az elküldendő adatoktól (pl. mennyiségétől), valamint attól, hogy a megrendelő milyen üzleti kockázatot hajlandó vállalni.
12

5 másodpercenként amit

kriszrap · 2016. Jún. 2. (Cs), 22.12
5 másodpercenként amit lekérdezek :

van e új üzenet
éppen íre
látta e
XMLHttpRequest használok
az lenne jó ha a szerver szolna hogy figyú "újinfok vannak kérdle"

ezt érzem ugy mond "erőforrás zabálonak"
13

Miért?

Hidvégi Gábor · 2016. Jún. 2. (Cs), 23.27
Haldoklik a szerver?
14

Kevés felhasználónál nem

smokey · 2016. Jún. 3. (P), 08.41
Kevés felhasználónál nem fogja észrevenni, viszont ha apache szolgálja ki, és rámásznak az oldalra 200-an (vagy többen) egyszerre, akkor lehetnek bajok. A WAMP (web application messaging protocoll) segíthet egyébként, ami websockettel és sima http kérésekkel oldja meg a problémát. Felveszel csatornákat, és ha érkezik valami interakció egy http kérésen keresztül egy másik irányból, akkor be lehet szólni egy csatornába, ami tovább irányítja az infót a csatornára feliratkozott kliensek felé. Az "éppen ír" funkció megvalósításának én is websocket-tel állnék neki. Valószínű olyasmi architektúrával, hogy sima http kérések kiszolgálását egy PHP-s alkalmazás végezné, a websocketes kommunikációról meg egy NodeJS app tökéletes; ha kell, akkor a PHP és a NodeJS app pedig tud kommunikálni egymással.
15

Igaz

Hidvégi Gábor · 2016. Jún. 3. (P), 09.18
Én ezekkel tisztában vagyok. Kriszrap viszont a legjobb tudomásom szerint 1, PHP-ban programoz, ahhoz képest viszonylag nagy váltás a Node.JS, ráadásul 2, ehhez szervert is kell találni (ami valószínűleg drágább, mint a PHP-s), 3, sejtésem szerint még nincs kétszáz felhasználója, és marketing híján lehet, hogy nem is lesz soha.
16

Egyetértek! Ha viszont

smokey · 2016. Jún. 3. (P), 10.42
Egyetértek! Ha viszont tényleg így áll a dolog, akkor érdemes először kéregetni az infót, és ha lesz rá igény, mert nagy a terheltség, vagy valami, akkor megcsinálni úgy, hogy az ne csak működjön, hanem jól működjön. Egyébként PHP-vel is lehet websocket szolgáltatást készíteni, viszont itt is lehetnek performancia gondok.

Szószó, kezdésnek tuti jó lesz az AJAXos kéregetés, ha rövid időn belül tényleg nem lesz nagy terhelés.
17

Halli :)) bocsánat a nagy

kriszrap · 2016. Jún. 12. (V), 21.22
Halli :))
bocsánat a nagy hatás szünet miatt .....
Ahogy olvasgattam mindenre választ kaptam akkor maradok az ajaxnál...
Websocket nem minden böngészö kompatibilis ugy tudom.
18

Azért elég ígéretes a

bamegakapa · 2016. Jún. 12. (V), 23.34
Azért elég ígéretes a helyzet.
19

Ööööö..... igaz:) PHPba hogy

kriszrap · 2016. Jún. 13. (H), 19.50
Ööööö..... igaz:)
PHPba hogy tudom ezt a websocketett megcsinálni???
egyéb kérdés:
Facebook is igy oldja meg???
20

Én a PHP-t nem javaslom ehhez

bamegakapa · 2016. Jún. 13. (H), 22.28
Én a PHP-t nem javaslom ehhez a feladathoz. Ha mégis erre vágysz, a Ratchet-et már láttam működni, illetve itt találhatsz még alternatívákat.

Szerintem a legegyszerűbben Node.js-el tudod megoldani. Vannak már kész könyvtárak erre, például a Socket.IO. Nekem ez eddig bevált.

Nem néztem utána, a Facebook konkrétan hogy csinálja, de gyanítom, hogy nem hívogatják a szervert másodpercenként. Ha valami realtime dolgot akarsz, websockettel érdemes szerintem nekiállni.

Sajnos occsó webszerveren nem valószínű, hogy a PHP-n kívül mást tudsz majd használni. Vagy úgy általában bármit telepíteni. Tehát könnyen lehet, hogy websocket kilőve.
21

hmmmmm:)) ez a Node.js

kriszrap · 2016. Jún. 14. (K), 11.13
hmmmmm:))
ez a Node.js igazából mi javascript alapu de mi??:)
Elkezdek ezen a gondolkozni nem a php-n:))
22

Javascript a

bamegakapa · 2016. Jún. 14. (K), 13.20
Javascript a szerveroldalon. Az interneten rengeteg anyagot találsz róla.

Minden feladathoz érdemes a megfelelő eszközt választani. Van, amire a PHP jó, van amire a Node, és így tovább. Érdemes megismerkedni minél több eszközzel, hogy majd a megfelelőt tudd választani adott projekthez.
23

köszönöm:)))

kriszrap · 2016. Jún. 14. (K), 15.17
köszönöm:)))