Server-Client timer synch

[penthy]

Skate, yardimci olmasi acisindan: Istemci ve sunucu arasindaki latency'i olcmek icin kendi algoritmani gelistirmektense, Windows TCP/IP stack'inden bu bilgileri isteyebilirsin.
 
Windows Vista ve Windows Server 2008 ile birlikte gelen yeni nesil TCP/IP stack'i ESTATS olarak da bilinen TCP baglanti tabanli gelismis istatistik destegi getiriyor. Gerekli API'lar iphlpapi'da:
 
http://msdn2.microsoft.com/en-us/library/bb485738.aspx
http://msdn2.microsoft.com/en-us/library/bb451840.aspx
http://msdn2.microsoft.com/en-us/library/bb451854.aspx
 
FINE_RTT diye arat. Bu istatistikler hem smoothed, hem cok granuler, hem de TCP rexmit gibi eventler hesaplarin icinde var. IPHLPAPI'i zaten oyle ya da boyle kullanmak zorunda olacaksin.
 
Windows 2000, Windows XP ve Windows Server 2003 de benzer ancak daha az granuler istatistikleri (baska API'lar ile) tutuyor. IPHLPAPI'dan aratarak kullanabilirsin.
 
Problemin cozumu icin IMHO, istemci'lerin karar vermesini kisitlamalisin. Sunucu zamani tick'lere bolmeli (1 tick == 100ms mesela), ve bu tick'ler icinde eline gecen bilgileri degerlendirip oyuncularin tick sonu itibariyle state'lerini butun istemcilere timestamp ile gondermeli. Istemciler "bu timestamp'te burada ise simdi yaklasik olarak surada olmali" gibi varsayimlarda bulunmamali, boylece cok granuler time sync gerekliligi de ortadan kalkar.

[skate]

@penthy: öncelikle "güncel" bilgiler için çok teşekkür ederim. aradığım şey aynen de buydu. elbette ki oyunu Vista, 2008 only yapmak gibi bir niyetim yok. bu yüzden eski standartlardaki en uygun çözüm üzerinden gideceğim. ticklere bölme konusunu daha önce hiç düşünmemiştim. bence çok güzel ve zekice bir çözüm. kesinlikle kullanacağım. genellikle iyi bir connectionda ping time'ın <100 ms olduğu düşünülürse 1 tick = 100 ms her ne kadar örnek bir değer olsa da oldukça da ideal bir değer. özellikle "ateş etme" gibi durumlarda client ne zaman ateş tuşuna basarsa bassın eventi ilk tick bloğunda tetikletmek hem server hem diğer clientlardaki problemi büyük ölçüde çözer. tekrar sağol

[disq]

ticklere bol diye ben diyecektim denmis. bildigim her fps engine'i aynisini yapiyor. ornegin source engine'de saniyede 33, 66 ya da 100 gibi degerler kullaniliyor. default olan 33 tickrate'in oyunculara yeterli gelmedigini de belirteyim.

seni bu konuda yeni gordum, q3 engine ve source engine konusunda connection optimization dokumanlari okumani tavsiye edeyim.

[skate]

evet bu konularda yeniyim ve zaten kendimi geliştirmek için uğraşıyorum bu projeyle. quake'in bu konuda süper optimizasyonları olduğuna eminim ancak 8-16 falan değil de 1000+ kişinin aynı anda bağlantı yapmasına göre optimize edilmiş bir connection tutorial'ı daha uygun olmaz mı? quake ile ilgili dökümanları her halikarda okurum o başka.

[disq]

o zaman open source star wars galaxies serveri var onun koduna bir bak.

ayrica quake degil quake 3. source engine daha basarili ve daha komplekstir, q3 yerine ona baksan daha cok bilgi sahibi olursun.

[skate]

starwars galaxies bende orjinal olarak var ve servera 6 ay para ödeyip bir kez girmemiş olmak gibi de bir kerizlik rekorum var (detaylara hiç girmeyelim)
 
source engine, quake 3 ve starwars galaxies, hepsini de inceleyeceğim vakit buldukça. tavsiyeler için teşekkür ederim.
 
aslında bir süredir bu projeye ara verdim ama her zamanki gibi ara vermem olaya biraz daha dışardan bakmamı sağladı ve yeni fikirler verdi bana. uzun süredir istediğim UDP olayını da ekleyeceğim engine'e. özellikle movement gibi şeyleri UDP ile çözmeyi düşünüyorum. connection, inventory ve benzeri şeyler için TCP/IP daha secure olacaktır diye düşünüyorum. bakalım şu tutorialları okuduktan sonra fikirlerim ne derecede değişecek. şu ana kadar daha çok forum tartışmalarını okudum ki elbette ki herkes "bence..." diye başlıyordu postlara