STP Timișoara Forum: infoTrafic STPT (RATT) - STP Timișoara Forum

Hai sa zicem ca programeaza serverele sa faca asta in orele de varf, dar nu aiurea tot timpul... Nu cred ca nu s-ar putea face un schedule cand si cate cereri sa faca serverul respectiv.

Sa dai vina pe terti pentru indisponibilitatea serviciului tau e putin cam...neprofesional Exista load-balancers, rate limiting pentru a mai stopa din elanul tertilor; de asemenea, sa servesti totul de pe o singura masina, astfel incat niste request-uri suplimentare sa blocheze tot sistemul iar este foarte prost gandit. Daca fiecare site din www ar fi fost indisponibil la fiecare incercare de DoS, web-ul n-ar mai fi existat. Morala este: ai grija de spatele tau si nu considera cazul ideal ca fiind regula.

Aceasta postare a fost editata de NDY: 24 aprilie 2017 - 20:58

NDY, la 24 aprilie 2017 - 20:57, a spus:

Din cate stiu (mai nou) sunt doua... Una din ele serveste dispeceratul, panourile si alte servicii interne, a doua aplicatiile, dar trecand prin serverul de web (de aici si problema cu forumul si pagina web). Sper sa gaseasca colegii o solutie.

Si sunt probleme pe ambele (deci si panourile + dispeceratul fac flood, ceea ce e posibil, daca fiecare panou din oras face cate un request la 30 de secunde), pentru ca uneori si pe panouri apare xx:xx la toate liniile dupa care isi revine (similar cum forumul sau site-ul sau aplicatia dau uneori service unavailable dupa care isi revin).

- Nu ar ajuta daca ar exista un serviciu web care sa returneze toate datele (toate liniile + toate statiile) in bloc, astfel incat celor cu servere externe sa le fie suficient 1 request / 30 de secunde ?
- Nu s-ar putea limita nr de request-uri / unitate de timp (de exemplu max. 1 request pe secunda pe IP, sau max. 100000 de request-uri / zi / IP, similar cu Google Maps - am reusit la un moment dat sa depasesc limita la Google Maps si nu m-a mai servit in acea zi) ? Mai ales daca s-ar face si prima parte, cu request-ul care returneaza datele pt toate liniile + toate statiile in bloc, nu ai avea nevoie de mai mult de 1 request / 30 de secunde, sau ~2500 de request-uri / zi (intre orele 0 si 4 nu prea ai ce sa request-ui).

Sper ca cei cu serverele externe nu iau datele in vechiul format unde trebuia sa interoghezi fiecare statie si fiecare linie in parte (in cazul ala e clar..., sunt probabil zeci de request-uri/secunda de la un singur tert).

Cei cu aplicatii externe, daca tot iau non-stop date de pe server-ul RATT si le cache-uie pe serverul lor, nu ar putea sa se "uneasca" cumva si sa foloseasca un server comun (pe care ar putea implementa un serviciu care sa returneze in bloc toate datele, si astfel mai multe aplicatii ale tertilor sa se serveasca de la acel server comun?

Cum spuneam, nu e domeniul meu de expertiza (cum se spune mai nou ), dar ma gandesc ca programul, scriptul, sau ce o fi cel ce ar putea face limitarea request-urilor, ar incarca si el la randul lui serverul, ajungand sa mearga la fel de prost. (ca atunci cand ai doua antivirusuri pe un comp mai vechi, mai putin potent)

Limitarea traficului nu "costa" foarte multa putere de procesare. Acea parte a sistemului de operare (sau a firewall-ului) care se ocupa de traficul de retea, *deja* aplica by default un set de reguli pentru trafic. Doar ca regulile alea sunt "ok, lasam cam toate cererile sa treaca". Adaugarea unei noi reguli, care zice "opreste traficul dinspre IP-ul cutare" nu cauzeaza vreo crestere notabila a puterii de procesare necesara.

In functie de sistemul de operare de pe server, se poate configura destul de usor. Pe linux, spre exemplu, exista utilitarul iptables; din 2-3 comenzi, s-ar putea elimina IP-ul serverelor care nu inteleg sa nu faca flood de requesturi..

Aceasta postare a fost editata de dAImon: 25 aprilie 2017 - 12:43

Bun, bun! Dar ce facem cu IP-urile dinamice? Plus ca daca blochezi un IP, revine maine cu altul.

Nu e vorba sa blochezi manual un anumit IP, ci sa limitezi nr. de request-uri / zi / IP. (De exemplu, maxim 100.000 de request-uri, iar daca s-ar face o modalitate astfel incat sa se poata lua datele in bloc, s-ar putea limita chiar la 2.500 - 3.000). Ideea e sa se vina si cu un sprijin pentru cei care vor sa-si faca aplicatii cu servere proprii, dar sa se impiedice flood-area. Nici eu nu ma pricep la configurari de servere si din astea, dar ma gandesc ca exista niste tool-uri care fac exact asta: limiteaza nr. de request-uri / perioada de timp / ip.
Iar daca revine cu altul si cu altul etc, cu singurul scop de a incarca server-ul, asta deja e DDoS (distributed denial of service) attack, si din cate stiu eu e ilegal, deci se pot lua masuri legale.

IP dinamic nu prea vezi decat la consumatorii casnici, serverele gazduite profesional tind sa aiba IP fix. Poti sa mai ceri din cand schimbarea de IP, dar atunci RATT vede iar ca vine valul de cereri de pe un IP nou, il baneaza si pe ala, etc
DDoS e ilegal doar daca-i cu intentie malitioasa, din ce stiu. Faptul ca-ti configurezi gresit serverul si trimite mai mult trafic decat uzualul nu inseamna ca-i ceva pedepsibil. (cred, nu cunosc legislatia din Romania pe tema asta)

De ce fel e intentia e greu de stabilit... Poti motiva oricand ca a fost o greseala, ca nu ai stiut sa faci o setare, etc.
Cred ca serverele de care vorbim sunt acasa la dezvoltatori, nu la vreun gazduitor de fite.

Un server casnic nu poate deservi zeci de mii de cereri zilnice, ceea ce cam e valabil la aplicatiile mai cunoscute (cea de iOS, cea de Android a lui Mihai Balint).

In alta ordine de idei, s-a lucrat la layout si s-au marit dimensiunile tabelelor?

Tot asa iti arata si acum? Am verificat la un telefon de 4 inch, cum ne-ai zis ca ai si tu, si se vede ok.

Pe un telefon de 4.7 inch se vede ok

Pe ecran de 5,1" si rezolutie de 1440 x 2560, se vede perfect, inclusiv in mod landscape.

Visor, la 25 aprilie 2017 - 19:46, a spus:

Fara sa reinstalez aplicatia: nu, arata la fel si la E1 si la linia 2.

Dupa reinstalare: E1 arata ok, insa 2 pe sensul spre Dambovita e tot decalat.

M-am mai uitat si prin alte linii, care mai sunt decalate: Tv1 (ambele directii), 4 (spre Ciarda), 5 (spre statia meteo), 7 (spre Torontal), 8 (spre Domasnean), 9 (spre Domasnean) ; M11 spre Baritiu, 13 spre pasaj C.F., M14 spre Dumbravita, 15 spre Grozavescu ... etc etc. Per total mai mult de jumatate din linii.

Telefonul pe care testezi ce rezolutie are? La mine e rezolutia de la screenshoturi.

La rezolutie nu s-a umblat deloc. Testez online pe 320*480 si merge.

Ahh, cred c-am descoperit care-i diferenta: face overflow atunci in lista timpilor se afla si simbolul " >> " (acela pentru vehiculul care se afla in statie).

Deci, pe aceeasi linie, daca e un vehicul intr-o statie, atunci face overflow. Daca mai astept un minut, si in lista cu timpii se afla doar chestii gen "HH:MM" sau "X min", atunci tabelul arata ok

Pai in loc de ">>" noi am pus demult timp un icon cu un mic mtc, dar si daca apare acel icon, tot nu trebuie sa faca overflow. Asa trebuie sa apara, testat pe 320*568.

Un sfat din experienta! Niciodata sa nu te bazezi doar pe ceea ce vezi in emulator. Intodeauna sa testezi pe un device! (mai ales daca interactionezi cu publicul )

Daca am postat acum print-uri din emulator, nu inseamna ca nu am testat pe device, doar ca n-am avut acum la indemana. Dupa cum am scris mai sus, am testat pe telefon Huawei de 4 inchi rezolutie 480*800 si era totul ok.

dAImon, in mod normal, nu trebuie reinstalata, nici updatata, fiind web-based, problemele le rezolvam online, pe server.