[uppercasesusan]

W ramach wprowadzenia, bo nikt nie doczyta do końca:

Jeżeli siedzisz na tagu w celu takim, by nie było tobie bądź twojej rodzinie zimno, a dalej masz zamiar głosować na PiS to dążę cię bezgraniczną niechęcią.

Po drugie, nie tak to powinno wyglądać. Jako lewak uważam, że osoby biedniejsze powinny mieć łatwy dostęp do niedrogiego polskiego węgla, zamiast całej tej szopki z dopłatami i loterią. Obecny burdel służy kręceniu dobrych lodów przez osoby, które takie lody mają kręcić; przy okazji otwierając furtkę dla cwaniaków.

Jak moim zdaniem wygląda stos PGG:

Na samym dole jest biedny p**lony backend, który w pocie czoła próbuje obsłużyć nasze zapytania. Instancji backendu na pewno jest dużo, no ale baza pod spodem jedna, nawet jeżeli clustrowana.

Kawałek wyżej jest middleware, który do niedawna był frontem. Jest to jakiś nginx albo haproxy. Jego zadaniem jest odrzucanie sesji (potocznie połączeń) ponad z góry określony limit, tak, żeby ochronić backend. Jak połączenie jest ponad limit to dostajemy Planszę Narodową (PN), która jest prostym fragmentem html, którego middleware pewnie nawet w pamięci trzyma, więc jest mu go łatwo zaserwować.

Wg mnie w ostatni wtorek wprowadzono nowy frontend: jakiś sprzętowy firewall Cisco albo cokolwiek co się teraz takiego instaluje; dawno się hw sieciowym nie interesowałem, więc nie wiem, co teraz popularne. Maszynka ta zupełnie nie rozumie ruchu, jedyne co robi, to jeżeli stwierdzi, że jakieś IP za mocno atakuje to odrzuca połączenie po zdefiniowanym czasie. Jestem przekonany, że mają ich więcej niż jedną i nie są one splecione ze sobą, czyli można dostać bana na jednej a wbić się na drugą. Nie wiem dlaczego odrzucają połączenia, robić się powinno coś innego, ale że nie dopłacają mi za konsultację, to nie będę im doradzał.

Jak ja kupiłem?**

Do tej pory udało mi się kupić dwa razy, raz matce a potem zapas sobie, bo palenie w kominku na dłuższą metę jednak męczące. Próbowałem dwa miechy, ale jak już pykło to tydzień po tygodniu 2x się udało, na internecie mobilnym.

Warunkiem koniecznym jest uzupełnienie profilu, wpisanie poprawnych danych, adres, PESEL, nr telefonu, CEEB. Niech ktoś z rodziny ci to sprawdzi, bo jak masz dane niepoprawne, to po co ta gra?

Do losowania używam chrome’a. Na codzień używam firefoxa, ale mam w nim doinstalowane tyle wtyczek, że wydaje mi się, że zaczęły interferować z pgg. Plus lubię przed każdą sesją wyczyścić zupełnie profil. Mam też wrażenie, że bycie zalogowanym do google accounts pomaga z captchą.

Na stronę logowałem się rano, a potem co godzinę F5, żeby zaktualizować talon (token) sesji. Ostatni raz robię to o 14:30. Talony są ważne 2h, a o 16:30 to i tak już tylko miał. Ten ostatni raz bywa ciężki, ale spokojnie odświeżam, aż zobaczę puste półki (PN się nie liczy). Narzędzia budowlane otwieram na sieci.

O 16:00 idę sobie zrobić meliskę na #!$%@?, że znowu nie uda się kupić. O 16:05 sprawdzwegiel pe el i jak tylko coś się pojawi zaczynam odświeżać. Robię to z sekundnikiem: jeżeli nie dzieje się nic przez 20s, przerywam i odświeżam; zapytanie i tak pewnie zginęło w sieci, więc nie ma sensu czekać. Na PN natychmiastowy refresh. Jeżeli w sieci zacznę zauważać odrzucone zapytania po niemal równo 5s to znak, że wpadłem w limit na frontowym firewallu: wtedy trzeba zagryźć wargę i ze spokojem nie robić nic przez 60s, żeby zapora o nas zapomniała. Wiem, że to trudne, ale jesteśmy na etapie, na którym najważniejsze jest załadować sklep, a front nam to będzie blokował. Niestety musimy tak robić, bo to jedyny sposób, żeby uzyskać talon produktu, bez którego nie można zrobić zakupów.

Jeżeli załaduje się nam sklep, wybieram towar, na który mam ochotę i klikam ikonkę koszyka przy tym towarze. W narzędziach budowlanych widzę to skazane na niepowodzenie zapytanie. Kopiuję jako curl i wklejam w konsolę. Ja to robiłem w pętelkach while true; do, etc, atakując na 2 baty, ze względu na zaporę frontalną. (W zeszłym tygodniu leciałem na 20 batów, i nie było z tym problemu). W wyjściu z curla będziemy widzieć, w jakim jesteśmy stanie. Może to być: PN; zapytanie odrzucone — jeżeli tych będzie bardzo dużo tak powiedzmy 90% to znak, że już nas nienawidzą i musimy odpuścić na 60s; 419 z kodem zgłoszenia — prawdapodobnie nasz talon produktu właśnie stracił ważność, ale nie jestem pewien, szerzej o tym niżej; przekierowanie na koszyk — 50% szans, że udało się kupić. Niezależnie od wyników próbujemy dalej, w tym samym czasie próbując załadować na nowo sklep metodą powyżej; jeżeli to się uda to podmieniamy curle w naszych zapytaniach. Przerywamy jedynie, gdy 419 się powtarza: nie ma sensu denerwować zapory frontowej, jeżeli i tak nie akceptują naszego talonu.

Kilka słów o talonie zakupu i przekierowaniu na koszyk. Wydaje mi się, że intencją było, żeby talon zakupu był zupełnie jednorazowy: backend go generuje, zapisuje w bazie, a potem pozwala za jego pomocą dokonać jednego zakupu. W teorii talon powinien tracić ważność w momencie, gdy backend zobaczy go po raz pierwszy, ale kiedy mi udawało się kupić, to też widywałem najpierw 419. Zdarzało się też, że widywałem przekierowanie na koszyk 2 razy z jednego talonu. Podejrzewam, że trzymają te rzeczy w jakimś biedomysql i ich rozwiązaniem na wydajność jest cluster bez pełnej spójności, co oznacza, że jeden backend może widzieć inny stan bazy niż pozostali. Ale możliwe, że sklep jest napisany przez studenta/profesora w php, który nie ma pojęcia jak się transakcyjnie robi takie rzeczy.
#pgg

[Ludwikvonmizez]

@uppercasesusan: Ja dzisiaj od 16 siedzę i tylko raz wszedłem na główna, nawet teraz nie mogę wejść (18) a co 20 minut sprawdzam wiec #!$%@? wie co oni tam nawymyślali, w telefonie już się udaje wejść ale nie da się dodać do koszyka

[thewickerman88]

@uppercasesusan: heh miałem bardzo podobne spostrzeżenia, z telefonu na chromie kupiłem przy 3 podejściu.