Eve Online > Dyskusje ogólne
Wielkie bitwy wreszcie możliwe ? + rożne
Ellaine:
1. Masz racje że tak powinno być i tak jest. Jedna fizyczna maszyna w klastrze obsługuje od 1 systemu do bogdajrze konstelacji czy może nawet regionu.
2. Owszem, mylisz się ;) Kiedy strzelam do wrogiego BSa, to całe zdarzenie, HPki i parametry celu są w pamięci noda, nie w bazie. Nie wiem kiedy dokładnie zapisują się i wczytują, niemniej krytyczne obciążeniowo operacje są w pamięci. Baza jest odciążana o tyle, że jest jedna i centralna a nie osobna dla systemów. Jest to raczej oczywiste z punktu widzenia projektowania, CCP mówiło o tym kiedyś pobierznie na forach. A dowodem na to że nie jest tak jak mówisz jest fakt, że Eve nadal działa i można się wydokować w czasie poniżej 3 godzin.
3. Ale są ograniczone.
Problemem z rozłożeniem obciążeń jest ten szczegół, że fizyczne nody są przypisane systemom/konstelacjom/regionom ręcznie, w czasie rekonfiguracji podczas downtime. Nie potrafią dynamicznie się przełączyć na obsługę mniejszego lub większego obszaru, w każdym razie nie porafiły kiedy ostatnio czytałem wypowiedzi CCP o problemach z wydajnością. Ale może się to zmieniło bo mówili też, że nad tym ostro pracują, a było to ponad pół roku temu.
Jeśli nie poprawili, to po prostu dużo większy lag jest w bitwach niezapowiedzianych, których CCP nie przewidziało. W miejscach gdzie CCP spodziewa się bitwy, tudzież w innej Jicie, jest już przypisany osobny node do systemu i jest jako tako.
Problem drugi polega na tym, że CCP nie potrafi(ło?) przpisać więcej niż 1 noda na system. Gdyby potrafili, moc obliczeniowa jednego systemu rosłaby do potencjalnie wielkich rozmiarów i teoretycznie mogłoby to ciągnąć wiele tysięcy w jednym systemie. Ale już niekoniecznie w jednym gridzie - tu właśnie tkwi problem. Żeby to zrobić, musieliby mieć kilka komputerów z wirtualnie współdzielonym ramem zawierającym np tablice ze statkami i ich parametrami, z których mikro-wątek każdego zdarzenia ("aktywuj laser!") mógłby sobie pobrać np ile HPków ma jeszcze cel żeby sprawdzić czy już wygenerować zdarzenie "boom" czy nie. CCP albo nie potrafi tego zrobić w ogóle (co możliwe), albo (co bardzo prawdopodobne) straty wydajności na dostępie do wspólnego ramu po sieci (nawet jeśli to super szybka sieć klastra) zarzynają ten koncept.
Problem trzeci polega na tym, że ilość obliczeń na np jakieś bumpowanie obiektów etc, wzrasta w najlepszym wypadku n*log(n) do ilości obiektów, czyli szybciej niż liniowo. Co oznacza że do bitwy na dwa razy większą ilość statków trzeba więcej niż dwukrotnie zwiększyć moc obliczeniową.
Problem piąty polega na tym że w CCP nie pracuje najwyraźniej nikt tak mądry żeby rozdzielić połączenie "nawigacyjne", do zdarzeń w kosmosie, od połączenia obsługującego rynki, itemki i inny syf. W tym temacie nie istnieją gridy i nlogn-owe wzajemne interakcje i spokojnie możnaby inaczej rozłożyć klaster niż są ułożone systemy. Gdyby istniała taka opcja, to rynek i chat w Jita działałyby płynnie i dałoby się tam normalnie latać.
Problemów jest pewnie więcej :)
Qreg:
Spojrzcie na to z troche innej strony, taka gra MMO jest niczym innym jak systemem ze zmiennymi opoznieniami, bo pakiety od kazdego z uczestników bitki docieraja do noda z roznym opoznieniem i tego CCP nigdy nie przeskoczy.
Te zmienne i niezależne od nich opoznienia sprowadzaja sie do laga, pominięcie tego przyczyniłoby sie do desynców co i tak niestety czasem sie zdarza. I tak naprawde jest to niezależne od devow i moc obliczeniowa nodów ma tu drugorzędne znaczenie.
iniside:
--- Cytuj ---Jedna fizyczna maszyna w klastrze obsługuje od 1 systemu do bogdajrze konstelacji czy może nawet regionu.
--- Koniec cytatu ---
No wlasnie o to mi chodziło, ze cały region dla jednej maszyny to za duzo, zdecyowanie :D.
Ale z drugiej strony stawianie osobnego serwera na kazdu ykład słonczeny, byłoby nieopisanym wręcz marntotrawieniem zasobów..
--- Cytuj ---3. Ale są ograniczone.
--- Koniec cytatu ---
No tak, ale jakos niechce mi sie wierzyc w obliczenia mowiac o wyslyniu danych w ilosci >5MB per client..
Podstawowe akcje (strzelaj, orbituj, lec, stoj), mozna zmieścić w paru bitach wielkiej filozofii nie ma.
Pozatym jesli jest duza bitwa nie trzeba kazdego osobno informowac iile statek ma HP (informuje sie tylko tego co ma namierzony dany okret inne clienta wogole nie interesuja). HP okretu da sie zapisac w maksymalnie 8bajtach. To i tak bedzie za duzo.
Teraz pomyslmy wraz ze strzałem jest przesylany typ, pozycja, itd.
Typ działa/amunicji/okretu (bonusy), da sie zapisać na 5 bajtach (dla kazdego z osobna), wkoncu jedyne co bedzie przysylane to ID przypisane do kazdego elementu, wszystkim innym zajmuje sie serwer, i znowu wysyła ID, które klient przypisuje do odpowiedniego elementu. (a w kazdym razie ja bym to tak zrobił gdybym projektował serwer).
Pseymistycznie rzecz biorac liczba danych wysyłanych/odbieranych moze urosnac do 1MB ale to ekstremalnych przypadkach imo. (oczywiscie na jednego klienta). Co i tak wydaje mi sie liczba mocno zawyzona :P.
Ellaine:
Nie przesadzajmy z tymi 5 bajtami, prawdopodobnie wysyłany jest typeID znany z bazy danych, a jest to conajmniej 4bajtowy int, czyli taki strzał to by było
4 bajty - rodzaj statku
4 bajty - rodzaj działa
4 bajty rodzaj ammo
tyle że raczej nie jest to wysyłane, z klienta wystarczy wysłać event "activate high slot 1" (serwer musi przecież wiedzieć co mamy w którym slocie) a z serwera "zadales 523 damage obiektowi 43444444" (klient musi przecież ten obiekt mieć załadowany).
Wolver:
Rodzaj ammo, broni, poziom skilla, implanty, fleet bonus. W międzyczasie mogą dziać się różne rzeczy - ktoś offline'uje lub włączy moduł, ktoś uruchomi ganglink, squad booser wyleci z systemu, crystal w laserze się zużyje.. A np. info o HP celu trzeba nierzadko wysyłać kilkuset osobom, bo mają dany cel namierzony. Drony też po drodze trzeba policzyć, a także skutki działania rigów na broń, drony, szybkość, zwrotność, tracking, overload..
Nie upraszczajmy tego zbytnio.
Nawigacja
[#] Następna strona
Idź do wersji pełnej