Jump to content

fedorffixxzz

Members
  • Posts

    47
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by fedorffixxzz

  1. Făcliile aprind încăperile nocturne,

    Oh! Cât romantism plutește pe aste unde.

    Unde ești acum iubito să îți simt a ta suflare,

    Să îți simt bătăi de inimă...

    Să îți simt a tale brațe?

  2. esti sigur? eu vad: nu e niciun spatiu dupa ":", este spatiu in valoarea (tratata ca string, ex. " 4321") detinuta de variabila? ai testat? poate asta e motivul pentru care firefox interpreteaza acel spatiu ce lipseste iar celalalte respecta strict rfc
  3. RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 este posibil ca tu sa omiti acel spatiu intre ":" si numar?
  4. Daca te ingrijoreaza performanta, implementezi directive si politica ca atunci cand vei compila codul, toate comment-urile sa fie inlaturate si alt garbage, daca nu se intampla deja asta. Sursa ramane comentata.
  5. Am nevoie de ajutorul vostru in a ma decide ce algoritm sa folosesc pentru urmatoarea problema. Se da o baza de date cu un tabel ce cuprinde 10 milioane de randuri: +---+-------+ | id | value | +---+-------+ ID: de la "a" la "n". Atunci cand baza de date porneste, scriptul meu cheama functia "get_values()" ce returneaza sub forma urmatoare fiecare id si valoarea sa: "'<id>':\t'<value>'" Scriptul meu la randul sau, este un wrapper, si returneaza un dictionar de forma urmatoare: dict = {'id[0]': 'value', ... , 'id[n]': 'value'} (faceti abstractie la forma de array pentru id-uri, exemplifica faptul ca returneaza fiecare id si valoarea sa intr-un dictionar). Un motor de testare injecteaza diferite input-uri incercand sa faca baza de date sa rezulte in crash. Odata ce baza de date a facut crash, un alt motor ce monitorizeaza va restarta baza de date cu tabelul si randurile cum au fost lasate ultima data, nu este nicio procedura de fail-safe sau abstractie intre parinte -> child pentru a izola fault-urile. Procesul se repeta, se returneaza un dictionar, insa de data asta se compara cu cel original. Sa zicem: control = {'a': 'a value', ... , 'n': 'n value'} crash = {'a': 'some value', ... , 'n': 'some value'} Presupunem ca doar jumatate din toate id-urile au ramas intacte, alta jumatate sunt rasfirate cu valori schimbate. Procesul urmator, este de a face diferenta intre acestea. Insa eu am posibilitatea sa specific functiei "make_diff(*exclusions)" ce sa exclud. De exemplu, nu vreau ca 'e' si 'f' (id-urile) sa fie comparate, asa ca le exclud si vreau sa mi se returneze fara ele. Tinand cont ca am i = 0, iterez prin cele doua in acelasi timp, asa ca in control si crash sunt aceleasi key comparate (valorile sale): control['a'] si crash['a'] cand i =0, apoi control['b'] si crash['b'] cand i = 1, etc. Insa nu cred ca este eficient, asta inseamna de la stanga la dreapta sa itereze prin fiecare. Divide et impera: Tinand cont ca am n elemente, incep de la jumatate: n/2. Daca elementul din stanga lui n/2 este diferit de n/2 (n/2 != n/2-1) atunci pornim in stanga, daca sunt la fel, pornim in dreapta: [ 0 ] [ ... ] [n/2-1] [n/2] [n/2+1] ... [n+1] [ n ] ----------------------/ \---------------------------- Este adecvat pentru aceste dictionare? Daca am un element dupa n/2-1 (n/2-2) care nu este la fel cu n/2, insa n/2-1 este la fel cu n/2 ar insemna sa pierd pe n/2-2 din moment ce pornesc spre dreapta. Ideea este sa returneze key-ul (exemplu: 'a') cu valoarea sa inainte ('a value') si apoi valoarea sa dupa ('some value'): 'a' -> 'before: a value | after: some value'. Si mai mult cred ca este o matrice 2d din moment ce nu am array ci dictionare. Ce credeti? Trebuie tinut cont ca pe un array 1d ar fi o complexitate de log(O)n banuiesc, iar daca luam 10 mil de intrari pe o iterare de la stanga la dreapta completa ar lua 15 secunde (presupunem), iar cu D et I ar lua 0.001. Daca luam 10 secunde pentru a ne conecta la baza de date, si 15 secunde sa luam toate entry-urile si sa le returnam comparate cu diferentele intre ele, iar daca inmultim astea cu 10 sisteme, ar insemna 250 de secunde, ceea ce este enorm de mult.
  6. Am dat recent de niste lectii video de la MIT de prin 2005 insa inca sunt solide pana in ziua de azi si invata lectii importante. Folositoare pentru programatori, designeri de sisteme sau in general cei ce au de a face cu interfete si limbaje joase (programare in ASM/C etc.). Pe scurt: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-033-computer-system-engineering-spring-2009/ Video lectures: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-033-computer-system-engineering-spring-2009/video-lectures/ In engleza.
  7. Se pare ca s-a uitat de tot de acest proiect foarte interesant. Am patchuit script-ul original realizand urmatorul changelog: fix client ^C, va trimite KILLME catre server acesta fiind sters din lista, de asemenea client-ul face SIGTERM fix server ^C, uneori ramanea blocat dupa ce afisa "[!] Forcibly closed." probabil in timpul incercarii log.close() introdus /KILLME in client, daca aceasta comanda este executata va fi anulat de server si nerecunoscut implementare server-side setsockopt pentru tuning-ul socket-urilor ce raman in stadiul TIME_WAIT, vezi: http://unixguide.net/network/socketfaq/4.5.shtml fix pentru KILLME, inainte conexiunea nu era cu adeverat inchisa, se foloseste acum SHUT_RDWR si .close() TODO: de testat comanda/comportamentul cu mai multi clienti -> server altele? DONE: de rectificat in client si server segterm-ul: try pe subprocess.Popen, la exceptie sa se faca .communicate() si conditiile pentru returncode etc. (prea tarziu acum) de testat daca la /KILLME clientul si conexiunea sa sunt flushed (nu ocupa socket cu server-ul aiurea => "self" DoS?), nu facea flush, odata la interrupt vedem ca ramanea conexiunea in FIN_WAIT, in acest moment clientul putea realiza o alta conexiune, intr-adevar, reinitializa socket-ul ce era pe FIN_WAIT insa nu este recomandat:$ netstat -antpul | grep 51337 tcp 0 0 127.0.1.1:51337 0.0.0.0:* LISTEN 12983/python tcp 0 0 127.0.0.1:38536 127.0.1.1:51337 [b][color=red]FIN_WAIT2[/color][/b] - tcp 1 0 127.0.1.1:51337 127.0.0.1:38536 CLOSE_WAITacum insa, este inchisa, ramane in TIME_WAIT insa nu pentru mult timp fix linia 434, trebuie identare la log.write("\n[!] Errors encountered.\n\n", MSGTOEXIT) sa cada sub if (prea tarziu acum) chat.py original: http://codepad.org/r9FCqTyC chat.py patches (old): patch0.1 :: http://codepad.org/Q6uJNAbH current chat.py patched (0.2): http://codepad.org/6mCZ9DO6diferenta (patch 0.1 - patch 0.2): http://pastie.org/private/0cthpd9lbvlbikmjfkqr7a Critici constructive?
  8. Un nou cartier rezidential este construit, iar tu esti programatorul principal si arhitectul software-ului pentru liftul avansat in mai multe blocuri. Urmatorul pseudocod reprezinta modul tau (eronat) de a gandi soft-ul pana acum: La apasarea butonului: 1. aloca memorie ce va fi folosita pentru a retine numarul etajului 2. pune etajul dorit in memorie 3. am ajuns la etajul dorit? 4. daca da, atunci am terminat 4.1 altfel: 4.1.1 asteptam pana liftul intra in starea de idle 4.1.2 porneste catre etajul dorit 4.1.3 elibereaza resursele folosite pentru stocarea # etajului Sursa: https://en.wikipedia.org/wiki/Memory_leak#An_example_of_memory_leak Alte variante si cu ce design ati veni, avand ca obiectiv facilitarea intre etaje de urgenta etc. Argumentati si extindeti discutia in alte exemple *NIX?
  9. Aveti postat Program fifo and lru page replacement algorithm | Operating System - nullpointer Programming World For Beginner de catre black_death_c4t in C, de aici la BASH in *NIX n-ar trebui sa fie dificil.
  10. Este posibil ca in argv[1] sa ai string termination (\0) sau prioritatea executiilor intre paranteze sa fie gresita? Sunt curios aici cu ce solutii ati veni pentru a preveni deadlock si a face sincronizare intre childs si parent. O alta abordare ar fi un socket (tcp/udp) sau fisier de tip fifo pe sistemul de fisiere.
  11. Mirror: Reversing a Keygenme Challenge / Keygenning / Serial Fishing / Downloads - Tuts 4 You
  12. http://haotik.ro/wp-content/uploads/2011/09/token_banca_transilvania.jpeg good luck
  13. La fel ca Usr6, ma bate 34h, trebuie sa fie un truc aici pentru a pacali validarea, altfel nu vad cum e posibil
  14. Inca n-am apucat sa-l incarc in debugger insa dupa modus operandi al maestrului sulea, banuiesc ca string-ul ascii ce vine introdus in casuta vine criptat si apoi comparat cu valoarea hardcoded. Asta ar inseamna, reverse la secventele de criptare, ca sa decripteze serialul hardcodat.
  15. Pentru Python PEP8. Document bun si pentru cunostintele generale ce se aplica unui programator si altor limbi de programare.
  16. Era si timpul. Sper ca sunteti bine. Din pacate sunt prea obosit sa continui acum, mi-am notat 4 pagini deocamdata cu rutinele magice de XOR, insa variabilele LOCAL si ARGumentele sunt de apreciat pentru joaca ce o aduc. Weekend-ul asta sper sa vin cu rezolvarea. Cu respect, F
  17. Este logic, insa cum transmite bitii? Care este motivul si care este mecanismul in spatele motivului? Lasand la o parte capacitatea necesara pentru transmisia pe cablu. Spre exemplu la 100 mbps cand sunt folosite toate firele, restul de fire ramase sunt folosite pentru a transmite un semnal continuu, iar cand o interferenta intervine, este calculata interferenta cu semnalul continuu pentru corectare. De ce la Gigabit sunt folosite toate cele opt fire?
  18. Ok. Insa am intrebat, de ce gigabit foloseste toate cele opt fire pentru transmisie/receptie si nu doar patru ca in 100 mbps? Care este motivul? Cum functioneaza transmisia si receptia? De ce 8 fire?
  19. Salutare, recent profesorul ne-a intrebat de ce cablul Ethernet Cat5e foloseste toate cele 8 fire pentru transmisia de date in comparatie cu Ethernet Cat5 unde sunt nevoite doar 2 perechi (4 fire) pentru 100mb si doar 2 perechi (4 fire) pentru 10mb? Stie cineva raspunsul? Va multumesc anticipat.
×
×
  • Create New...