Systemy prawie czasu rzeczywistego - jak to realizować?

Siedzę sobie i teraz mi się przypomniało, a myślałem o tym i wcześniej. W jaki sposób realizowane są systemy działające praktycznie w czasie rzeczywistym w aplikacjach internetowych? Chodzi mi dokładnie o takie rzeczy w jaki sposób realizowane jest zamykanie aukcji w Allegro (skoro można strzelać z dokładnością do kilku sekund) czy te zabawy z flotami na Ogame?

Mogę sobie wyobrazić uruchamiany co minutę skrypt przez crona który wykonuje odpowiednie zapytania na bazie danych. Ale jak to zrobić z dokładnością sekundową, cron tego nie wytrzyma, a raczej serwer.

Jakieś idee?

skoro to ich serwery to mogą tam uruchamiać co chą nie musza to być skrypty uruchamianie przez crona ale raczej coś jak cron działające non stop

poza tym to wcale wbrew pozorom nic nie musi działać non stop, wystarczy że chociażby sprawdzi coś co minutę i to już wystarcza, jedynym skutkiem czegoś takiego będzie opóźnienie wysłania maila o zakończeniu aukcji o minutę, a patrząc z tej strony to jeszcze nigdy mi mail z allegro nie przyszedł w ciągu minuty od jakiejś akcji co wcale nie musi zależeć tylko od poczty

zaś na ogame w ogóle nie musi być niczego działającego w tle, wystarczy że podczas odwiedzin strony wszystko się poaktualizuje a bez odwiedzin to nie ma nawet takiej potrzeby
chociaż na pewno nie jest to zrobione w ten sposób bo przy większej liczbie userów system by się zamęczył

Adamo napisał(a)

zaś na ogame w ogóle nie musi być niczego działającego w tle, wystarczy że podczas odwiedzin strony wszystko się poaktualizuje a bez odwiedzin to nie ma nawet takiej potrzeby
chociaż na pewno nie jest to zrobione w ten sposób bo przy większej liczbie userów system by się zamęczył

Uuu, czemu mialby sie zmeczyc? Ostatnio pracowalem nad mmogiem podobnym do OGame (z tym, ze normalna realtimowa aplikacja - 3d i te sprawy) i nawet tam nie aktualizowalem wszystkiego nonstop (choc jak zaczynalem to oczywiscie sobie myslalem, ze kazda jednostka bedzie miala swoj watek, tam while(1) i bedzie sobie liczyc co trzeba - wtedy to by sie dopiero zmeczyl :D). Zalezy jakie ficzery mamy w grze, wezmy takiego ogame, tam dwa glowne ficzery to latanie i atakowanie. Gdy flota leci, jej pozycje musimy tylko sprawdzic jesli ktos "patrzy" na miejsce docelowe, czyli powiedzmy, ze Ktos wyslal flote na moja planete, w momencie gdy ja sie loguje system sprawdza czy flota Ktosia doleciala do mojej planety, jak doleciala to sobie liczy walke i modyfikuje co trzeba (jak lecialo wiecej flot to nie widze problemu zeby zrobic z tego kolejke).

Tak na marginesie to w aplikacji realtimowej serwer nie robilby wiele wiecej bo nawet jesli chcemy zeby gracz widzial jak ta jego flota leci to jej tor moze sobie liczyc klient :)

Generalnie doszedlem do wniosku, ze przy dewelopowaniu takich rzeczy nie nalezy przesadzac z abstrakcja - lepiej pierw pomyslec co program ma robic a potem dopiero jak.

jeśli wszystko by było optymalnie zrobione to nie ma sprawy, ale lepiej im jednak zrobić prosty program na serwerze który co minutę będzie przetwarzał kilobajt danych niż skrypt który podczas ładowania po długim czasie nie używania miał przeliczyć całą galaktykę

ale gra musi być z góry robiona na takie aktualizowanie w locie, nie ma mowy o tym żeby ktoś najpierw utworzył bazę danych i całą grę a potem myślał jak do tego dorobić skrypt aktualizujący

swoją drogą niektórzy myślą nawet że na ogame jak są te czasy ile pozostało do końca jakiejś budowli czy czego tam, to one są każdy jeden aktualizowany co sekundę na serwerze ...

Adamo napisał(a)

jeśli wszystko by było optymalnie zrobione to nie ma sprawy, ale lepiej im jednak zrobić prosty program na serwerze który co minutę będzie przetwarzał kilobajt danych niż skrypt który podczas ładowania po długim czasie nie używania miał przeliczyć całą galaktykę

Liczymy tylko to co trzeba, czyli wtedy gdy atakujacy lub atakowany sie loguje lub jak ktos inny bedzie chcial atakowac dana planete, imo to wystarczy i nic sie nie powinno zapchac.

jak się tak dobrze zastanowić to ani ogame (czy podobny) ani allegro wcale nie muszą niczego sprawdzać co xx sekund (minut). Na allegro jeśli chcesz licytować to czas sprawdzany jest w momencie próby licytowania, wcale nie musi być sprawdzony sekundę wcześniej czy później. Tak samo na ogame - zauważcie, że czas wyświetlany w przeglądarce (do przylotu, ukończenia budynku itp) jest fikcyjny - to "tykanie" załatwia timer w js po stronie klienta i synchronizowany do serwera jest tylko przy odświeżeniu strony. Natomiast same bitwy też nie muszą się "fizycznie" odbywać w konkretnym momencie - wystarczy, że następny odczyt danych spowoduje aktualizację i tyle.

Zauważcie, że w tych "systemach czasu rzeczywistego" wszystkie dane zapisane są w bazie. Nic nie stoi więc na przeszkodzie, żeby zapisać także np. 12.04.2006, że 24.07.2007 o 1321 ma się stać to i to, a przeglądarka (znaczy trzeba odpowiednio zaprojektować tabelę i vidoki do nich itd) odczytując dane uwzględni wpis z 12.04.2006 i dane wynikowe będą odpowiednio do tego wpisu zmodyfikowane

a ja myślę, że w tego typu systemach jest coś pomiędzy - na takim allegro kończenie aukcji przez określony program (c++?) byłoby piękną, wielką jak stodoła dziurą - wystarczy, że program (i tylko on) się wysypie, a żadne aukcje się nie będą kończyć, może się pojawić się przekozacka niespójność bazy danych i inne kwiatki :P.

Z drugiej strony liczenie wielgachnej kolejki zdarzeń po dłuższym opierniczaniu się też nie jest dobrym pomysłem - jak wiadomo obciążenie należy rozkładać jak najrównomierniej (dlatego backupy na serwerach się robi w nocy)