Filozofie komunikace klient - server – .NET – Fórum – Programujte.com

Potřeboval bych další radu :-))

Co méně vytěžuje procesor? A taky, která z těchto dvou metod se používá v praxi (např. ve hrách)?

Mám klienta, ve kterém potřebuji aktualizovávat ze serveru list místnosti do, kterých se můžou  následně připojovat.  A napadají mě dva způsoby jak aktualizovávat ten list a nevím který z nich je ten lepší.

1) Způsob, který i ted používám je, že každou vteřinu požádám server, aby mi poslal jeho aktuální list místností. Což u tohoto způsobu se mi zdá, že dost zbytečně vytěžuji server vzhledem k tomu, že je velmi pravděpodobné, že mi vrátí stejný list jako nyní mám, jelikož tam žádná nová místnost za tu vteřinu nevznikla ani nezanikla.

Pro ukázku můj kod:

            while (GameStates.Room == GameState.GetCurrentState())
            {
                lobbies = Query.GetLobbies();
                if (listBox1.Items.Count != lobbies.Count)
                {
                    listBox1.Items.Clear();
                    for (int i = 0; i < lobbies.Count; i++)
                    {
                        ListItem listItem1 = new ListItem();
                        listItem1.Text = string.Format("{0}   {1}/4", lobbies[i].Name, lobbies[i].NumberOfPlayers());
                        listItem1.Color = Color.White;
                        listBox1.Items.Add(listItem1);
                    }
                }
                Thread.Sleep(1000);
            }

2) Způsob o kterém přemýšlím, že bych tam implementoval je ten, že server si o každém klientovi bude vést údaje v jakém stavu se aktuálně nachází a pokud bude ve stavu, ve kterém bude čekat na list místností, tak server neustále bude kontrolovat jestli v jeho listu místností nějaká nová přibyla nebo naopak ubyla a poté by tento list až poslala všem svým klientům. Ale u toho se mi zase zdá jestli moc nevytěžuji server, jelikož to asi budu muset spustit tuto kontrolu na dalším novém vláknu.

Jinými slovy o aktualizaci listů na straně klienta by se měl starat server, nebo klient?

Co si o tom prosím myslíte?

Díky :-) 

#1 Kubas129
Typický případ užití vzoru Observer:

1. Klient si na serveru zaregistruje žádost o aktualizaci místností
2. Server si eviduje seznam žádostí klientů - abonentů
3. Pokud nastane změna stavu místností, rozešle oběžník abonentům
4. Klient na tento oběžník zareaguje tak, že si ten seznam místností stáhne a provede si aktualizaci

#2 Kit
aha díky :-) 

jdu si to nastudovat jak se to implementuje :D

#2 Kit
onoasi  i něco podobného pak bude s chatem pokud ho tam budu chtít mít v té hře

Myslím, že seznam hráčů mají všichni stejný (např ve skupině) a tak stačí aby server při příchodu nebo odchodu hráče (do/ze skupiny) rozeslal oběžník (členům skupiny) s novým seznamem. Jen selský rozum bez návrhových vzorů.

hu

#5 hlucheucho
Když se změní počet položek v listu, tak List<T> neumožnuje žádnou událost nějakou typu: počet položek se změnil?

Jsem si vygooglil, že na to je nějaký BindingList<T>. Jaký je mezi prosím nimi rozdíl? Můžu tento list v pohodě používat místo klasického List<T>?

Jak se změní List? Přece tím, že do něj přidám položku nebo položku z něj odeberu. Tedy samotné přidávání nebo odebírání položky je tou událostí která vyvolá update seznamů u klientů.

hu

#7 hlucheucho
a jo, můžu ještě poprosit o názorný kod, který po přidání a odebrání  prvku do/z listu zavolá void metodu()?

Se o to pokouším, ale mám s tím nějaký problém :(

list.Add(neco);
ListChanged(list);

Hráče do Listu přidáváš voláním jeho (= Listu) metody Add. Následně pak zavoláš metodu, která rozešle nový seznam. Je otázka, kterému objektu metoda patří, jakou má viditelnost...  A zase jsme u návrhu co který objekt dělá a jak objekty mezi sebou spolupracují.

hu

#9 gna
obávám se, že v jeho případě to takto přímočaré nebude. Ale je to jen domněnka.

hu

#9 gna
když tohle není úplně co hledám. Když přidávání a odebírání prvků  do/z listu mám v n metodách, tak bych chtěl spíše nějakou událost, nebo něco takového která by mi pro provedení této operace automaticky zavolala tu metodu a nemusel jsem se pokaždé, když do listu přidám a odeberu prvkem starat ještě o volání této další metody :(

Tak si napiš metody AddUser, RemoveUser a uvnitř těchto metod volej vše potřebné, co se změnou seznamu hráčů souvisí. A tam, kde se seznam hráčů mění, volej tyto metody. Myslím, že si zbytečně komplikuješ život.

hu

#13 hlucheucho
Jo to by asi šlo, nějak mě to ani nenapadlo, že by se to taky dalo udělat takto, díky :-))

ps. nemá někdo zkušenost ještě s tím BindingList<T>, který má přímo události pro změny prvků? Jinak je docela i zajímavé, že se tento list nenachází ani v knihovně System.Collections.Generic.

https://docs.microsoft.com/cs-cz/dotnet/api/system.componentmodel.bindinglist-1?view=net-5.0 

System.Collections.Generic

#13 hlucheucho
Já si zase myslím, že si ho spíš ulehčuje a to tím, že píše sem (na české forum) aby jsme mu vymysleli řešení, které si stejně udělá úplně jinak namísto vyhledávání na google, kde vše na co se tu ptal je lehce dohledatelné do pár minut i s examplama.

Pokud jsem to dobře pochopil snaží se udělat něco v XNA (nejsem si přesně jist, ale nepřestal se XNA nějak před několika lety vyvýjet?) Nebylo by pro něj lepší na tu hru použít nějaký gameengine (např. Unity3D též v C#) s tisicema návodů na yt, či dokonce přímo na jejich ofic. stránách?

#15 Mutagen
No vychází to z XNA.

https://www.monogame.net/

#16 Kubas129
Tak co třeba zkusit Unity3D? Též se v tom píše v C# a nemusel bys řešit žádný vlákna (pokud bys vysloveně nechtěl), mnoho návodů skoro na vše, a je to doslova GameEngine, takže lehčí práce s objektama, animacema, apod.

#17 Mutagen

Na ten MonoGame jsem si už nějak tak zvyknul a hlavně už mám cca 50% té hry napsanou a ty kolekce bych tam stejně i tak musel podle mě řešit. Jinak co se týče ještě toho listu, tak jsem narazil ještě na jeden typ kolekce ObservableCollection<T>, která má přímo událost na, která se vyvolá v případě, že je položka přidána, odebrána, změněna, přesunuta nebo je obnoven celý seznam.

Což se mi zdá taky jako fajn :-)

#18 Kubas129
A to je tak těžký si napsat vlastní proceduru na změnu jak tu někdo už psal?

AddUser, RemoveUser, apod a k tomu udělat jednu univerzální listChanged(list) kde provedeš přesně to co potřebuješ např pošleš klientům a oni si nový list nastaví? Hledáš něco složitého v něčem co je úplně triviální.

#19 Mutagen
Vynalézat hranatý kolo je zábavnější :)

hu

Jestli trváš na událostech, můžeš si udělat potomka třídy List a události mu dotvořit takto: potomek bude mít 4 pomocné atributy OnBeforeAdd, OnAfterAdd, OnBeforeRemove a OnAfterRemove, do kterých se bude ukládat delegát na metodu obsluhující událost. Dále u potomka překryješ metodu Add, v jejím těle pomocí delegáta zavoláš událost BeforAdd, pak zavoláš Add metodu předka a nakonec pomocí delegáta událost AfterAdd. Totéž uděláš pro Remove.

Napíšeš hromadu kódu, dá to hromadu práce a nasekáš v tom hromadu chyb.

Kdyby takové události měly smysl, asi by to třída měla již implementované.

hu

Ještě pozn.: bramboračku nebo guláš mám raději na talíři.

Když použiješ ObservableCollection tak tak je přímo událost při změně kolekce to by ti mělo stačit, používá se to i ve WPF a MVVM