Lazy Item ID

[ɑce]

Türkiye'nin ilk OldSchool MOBİL 1-99 Sunucusu Sezar2 9 Ekim'de Açılıyor! Rekor Açılışı Kaçırma! HEMEN TIKLA!

Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.

64BİT gecemedik.....

 

[xNervouS]

64BİT gecemedik.....

Crossplatform tum işletim sistemlerine geçmiş adamsın 64bit sana dokunur mu?
Lazımsa sama 250euroya falan geçiriyor serverı 64bite

 

[ɑce]

Crossplatform tum işletim sistemlerine geçmiş adamsın 64bit sana dokunur mu?
Lazımsa sama 250euroya falan geçiriyor serverı 64bite

client yeterli geldi

 

[Agora Metin2]

Item id oluşturmadaki ana sorun 10M primary + 10M reserve’in core başına dağıtılması, 4 core 4 ch bir oyun için ch4 core4’te bir oyuncunun item elde etmesi demek bir sonraki restartta 150M range tek bir seferde boşa harcanmış olacak çoklu core sorununu bu çözmüyor.

Bence burada iki çözüm var Item id generation’ı merkezileştirmek yada benzer problemleri çözen dağınık sistemlerdeki id generation mekanizmasını kopyalamak (@Koray' ’ın verdiği örnek, core spesifik key ile oluşturulduğunda idlerin çakışma ihtimali olmaması) böylelikle her game core’un on demand kendi id sini üretebilmesi.

Eline saglik, tesekkurler.

 

[Tunga]

AddressSanitizer açık test yapmışsın, güzel. Şimdi testin neyi gösterdiğine de bakalım: AddressSanitizer bellek hatalarını yakalar; eşyanın doğru ID ile kaydedildiğini, sahipliğinin korunduğunu veya yeniden başlatmadan sonra sağlam döndüğünü doğrulamaz. Metinde AddressSanitizer geçmesi, paylaşılmayan test sonuçlarının boşluğunu doldurmuyor.
1070 + 8 − 2 = 1076 hesabı da doğru. Fakat dört işlemi bu kadar vurgularken kanal geçişi, takas, depo, yeniden başlatma ve ID tükenmesi sonuçlarını atlamak biraz tuhaf. Sekiz ID’nin ardışık çıkmasıyla ilgili oldukça konuşkansın; sistemin zorlandığı senaryolara gelince aynı ayrıntıyı göremiyoruz.
Üstelik SET_ATTR ve SET_SOCKET loglarında tahsis öncesinde ID sıfır olabiliyor. Eşya sonradan kalıcı ID aldığında önceki kayıtları hangi tekil eşyaya bağlayacaksın? Tasarruf ettiğin dokuz ID’yi tek tek saymışsın; karşılığında kaybolan log bağlantısını değerlendirmeye sıra gelmemiş anlaşılan.
SaveSingleItem() sıfır ID’yi kontrol ederken ForceFlush() aynı kontrolü yapmıyor. Bunun tükenme anındaki sonucunu gösteren test nerede? Konu ID alanının bitmesi, ama sunduğun örnekte alanın bittiği senaryo yok. Tam da anlatının merkezindeki sınırı test raporunun dışında bırakmak ilginç bir tercih.
Optimizasyonun faydası anlaşılmış durumda. Artık sunumun özgüvenini biraz da test kapsamıyla desteklersen, okuyucuya hesap makinesinden daha fazla inceleme malzemesi vermiş olursun.

ID’lerin hiçbir zaman geri kullanılmadığını hangi DB tahsis mekanizmasına dayanarak söylüyorsun? BuildRange() blok başlangıcını MAX(id) + 1 üzerinden yeniden hesaplıyorsa, kayıtlı maksimumun üzerinde tüketilmiş geçici ID’ler tekrar dağıtılabilir. Sende bunu engelleyen kalıcı bir tahsis sayacı mı var? Varsa onu da göster; ‘hiçbir zaman geri kullanılmaz’ kadar kesin bir cümlenin kod tarafında karşılığı olması gerekiyor.

Item id oluşturmadaki ana sorun 10M primary + 10M reserve’in core başına dağıtılması, 4 core 4 ch bir oyun için ch4 core4’te bir oyuncunun item elde etmesi demek bir sonraki restartta 150M range tek bir seferde boşa harcanmış olacak çoklu core sorununu bu çözmüyor.

Bence burada iki çözüm var Item id generation’ı merkezileştirmek yada benzer problemleri çözen dağınık sistemlerdeki id generation mekanizmasını kopyalamak (@Koray' ’ın verdiği örnek, core spesifik key ile oluşturulduğunda idlerin çakışma ihtimali olmaması) böylelikle her game core’un on demand kendi id sini üretebilmesi.

Eline saglik, tesekkurler.