Witam.
Od dawna zastanawiam się na jakiej zasadzie działają tzw. strzały w serwisach typu snajpier.net

Czy w tle chodzi non stop skrypt sprawdzający czy ma coś strzelić ? ( np w PHP )

Czy po dodaniu strzału ustawia się jakoś CRONa? Może w tle chodzi jakiś deamon?

Jak to jest z realizacją z tymi sekundami przed zakończeniem tzn czy np jedna sekunda przed zakończeniem daje nam gwarancję strzału?


Bardzo prosiłbym o podzielenie się spostrzeżeniami na ten temat.

pozdrawiam

Najprawdopodobniej. Ew. skrypt, który działa w pętli nieskończonej sprawdzając listę strzałów do wykonania.

Myślałem nad takim rozwiązaniem jednak jest to chyba najbardziej prymitywne i kojarzy mi się z aktywnym czekaniem czyli fujjj.

Nie da się np dynamicznie przestawiać crona albo dodawać zadań. Słyszałem, że żeby dodać coś do cron'a trzeba go potem zrestartować aby (zaskoczyły) zmiany.

Nie trzeba.

Cron ma najmniejszą rozdzielczość jednej minuty a tolerancję nawet ponad 59 sekund. Wszystko zależy jak bardzo system jest obciążony.

A wiesz, że najprostsze rozwiązania są najlepsze?

Tak samo i tutaj - chyba że wolisz ręczne klepanie demona działającego w czasie rzeczywistym.

Ale przecież czas do zakończenia aukcji jest chyba znany? Wystarczy zsynchronizować zegar serwera z portalem aukcyjnym lub zbudować klasę przechowującą aktualny czas na różnych portalach (jeśli aplikacja ma obsługiwać wiele serwisów aukcyjnych). Moim zdaniem problem leży w ustawieniu optymalnego momentu "strzału", przecież wysłanie nagłówka http i jego realizacja przez serwer trwa jakiś tam czas i czas ten może być różny od warunków. Ideałem byłoby wysłać na 0,0(0)1 sekundy przed końcem, ale czy wtedy zaliczy? Samo odpalenie skryptu w momencie, kiedy kończy się aukcja nie powinno być problemem.

No właśnie cały temat rozchodzi się o to. Jak to zrobić? Jak ustawie strzał na 15:40:43 to jak wywołać skrypt np sekundę wcześniej ?

A nie możesz zrobić listy zadań po prostu do odpalenia z uwzględnieniem tego offsetu?

Mógłbyś nakierować mnie jak się realizuję taką listę na serwerze? Jakiś kawałek implementacji czegoś takiego? Nigdy wcześniej nie miałem do czynienia z tego typu problemem i szczerze mówiąc nie wiem jak się za to zabrać

No najprościej byłoby zrobić listę zdarzeń do wykonania, coś w stylu własnej implementacji CRONa; pętla nieskończona w skrypcie ze stosunkowo małymi opóźnieniami (rzędu 200ms) i za każdym razem sprawdzasz listę.

Na niej zapisujesz czas wykonania strzału, a nie końca aukcji i opóźnienia. Jeśli jest strzał, startujesz osobny wątek strzelający, aby nie blokował głównego skryptu. Można powiedzieć, że to podział master-slave. No i po strzale oczywiście wyrzucasz z kolejki.

Gdzie zapisać? Płaska baza danych, choć blokowanie może być różne, jeśli chodzi o czas.

Możesz spróbować z jakąś bazą opartą o RAM.

Jednak nadal myśle, że jest to aktywne czekanie. Nie po to używa się triggerów żeby korzystać z aktywnego czekania. Pozatym musiałbym curlem wyowaływać rekurencyjnie funkcję żeby nie przekroczyć czasu wykonywania skryptu jak by to było przy zwykłej rekurencji.

Aktywne czekanie? A myślisz, że jak działają demony? Jest to tak naprawdę pętla nieskończona; nawet na płycie głównej wykonuje się coś w rodzaju pętli nieskończonej, tylko jest to tak skonstruowane, że tego nie zauważasz.

Więc mam pomysł taki, że można to zrobić rekurencją lecz nie taką zwykłą (chodzi o limit czasu wykonywania skrpytu) tylko za pomocą CURLa.
Mam jedno ale. Jak sprawdzić czy np coś nie poszło źle i trzeba uruchomić skrpyt jeszcze raz. Chce mieć 100% pewności działania. Jakoś średnio podoba mi się skrypt, który uruchomię przy starcie i będzie działał przez 3 lata.

Może da się zrobić coś ala skrpyt wykonywany co 10 minut, który będzie się tak długo wykonywał i przy uruchomieniu kolejnego ten stary przestanie działać. Czy moje myślenie jest słuszne czy może nazbyt kombinuję.

Jak to wszystko ma się do obciążenia bazy danych? Np pobieranie rekordów co 10 sekund.

Najłatwiej było by to napisać w jakimś C/C++, takie języki nie miały by problemów z nieskończonymi pętlami i jakąś prymitywną rekurencją

-- WebNuLL

Zapewne też przeszkadzało by Ci jeżeli serwer miały uptime rzędu 3-ech lat... Jak coś ma działać cały czas to niech działa cały czas.
Sposób opisany przez erixa nie dość, że banalny w implementacji to wydaje się być po prostu najłatwiejszym rozwiązaniem - do tego szybkim.

Coś pokroju:

[JAVA] pobierz, plaintext 
//...
while (true) {
  //sprawdź czy są jakieś akcje do wykonania ( = pobierz dane z bazy, gdzie jakaś kolumna z czasem jest mniejszą bądź równa aktualnemu czasowi )
  new ShooterThread(abc); //gdzie abc to jakiś tam obiekt "zadanie do wykonania", a ShooterThread to wątek, który wykonuje "strzał"
  Thread.sleep(200);
}
[JAVA] pobierz, plaintext 

Do tego wspomniana baza danych "oparta o RAM" (MEMORY w MySQL, SQLite itp.), uruchamiasz to i niech sobie działa w tle.

Obciążenie samej pętli będzie niemalże zerowe... trzeba jedynie nieco to rozbudować, upewnić się że dana akcja nie będzie wykonywana dwa razy równolegle itp. itd.

Nigdy nie będziesz miał 100% pewności. Powód? A skąd wiesz, że pakiety po drodze nie zostaną zgubione (np. w godzinach szczytu) i czas wywołania zostanie wydłużony?

O ew. przeciążeniu serwisu aukcyjnego nie wspomnę.

Wniosek: nie ma 100% metody.

Mam podobne rozwiązanie, które sprawuje się wyśmienicie, a przy tym jest banalnie proste. Ustawiasz CRONa by odpalał Twój skrypt co 10 minut. W odpalanym skrypcie ustawiasz maksymalny czas pracy powiedzmy na 9 minut i 55 sekund (niech będzie te 5 sekund "straty" w ramach asekuracji). To jest najprostsze rozwiązanie. Możesz również sprawdzać czy skrypt faktycznie chodzi. Jak? Uruchamiając skrypt zakładasz blokadę na jakiś plik (np. chodze_sobie.txt). Jeśli innym skryptem możesz ten plik otworzyć to znaczy, że skrypt nie chodzi (ten "ważniejszy"). Pewnie zastanawiasz się "a co ze zdejmowaniem blokady pliku?". Otóż jest ona zdejmowana automatycznie po zakończeniu wykonywania się skryptu, który ją założył (czyli również po przekroczeniu czasu wykonania).

@phpion: 5 sekund przerwy co 10 minut sprawia, że program statystycznie w ogóle nie uruchomi się w jednym na 120 przypadków, doliczając do tego jakieś tam prawdopodobieństwo innego losowego zdarzenia uniemożliwiającego wykonanie się "strzału" może nam dojść do tego, że program zawiedzie w jednym na 60 przypadków co jest raczej miernym wynikiem.

Oczywiście prawdopodobieństwo "zdarzenia losowego" to sobie tak na oko wybrałem - zapewne znacząco się ono różni od prawdziwego.

Nie wiem dlaczego autor tak bardzo boi się tej nieskończonej pętli... pół świata na takich działa

Też mi się tak wydaje. Mam też wrażenie że @BugsBunny cały czas myśli o skryptach uruchamianych z przeglądarki co tutaj rzeczywiście jest żadnym rozwiązaniem. Natomiast rozwiązanie @erix -a to z tego co zrozumiałem deamon uruchamiany z wiersza polecań (popraw mnie @erix jeśli się mylę).

Też teraz nad podobną rzeczą pracuję, ciekawy watek jest tutaj:
http://forum.php.pl/lofiversion/index.php/t41548.html