L4MP: Liberty City 4 Multiplayer

[spirit]

Spirit sanırım gerekli cevabı vermiş 

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

[deksdeveloper]

Spirit sanırım gerekli cevabı vermiş 

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

[spirit]

Spirit sanırım gerekli cevabı vermiş 

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

Niye buraya özel olsun, mühendislik terimleriyle GTAMulti ahalisine hava mı atayım... İş.. eskiden bu sektördeydim. Şimdi de bir butik kafe açsam iyi olur aslında

[xeoNNN]

Spirit sanırım gerekli cevabı vermiş 

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

Niye buraya özel olsun, mühendislik terimleriyle GTAMulti ahalisine hava mı atayım... İş.. eskiden bu sektördeydim. Şimdi de bir butik kafe açsam iyi olur aslında

kafe sarar da butik sıktı

[spirit]

Spirit sanırım gerekli cevabı vermiş 

Yok, ben sadece bir şeyler öğreniyorum. PAWN'a yeni başladım, kendimi geliştirmem gerekiyor. OnPlayerConnect'e müzik eklemeyi öğrendim dün. :/

Ağabey yanlış anlamazsan ne iş yaptığını merak ettim. Normaldede böyle ingilizce terim dolu mu konuşuyorsun yoksa buraya özel mi? Okurken kendimi sorguladım... Her şeyin türkçesini yazmaya çalışan biri olarak okurken kalbim sıkıştı

Niye buraya özel olsun, mühendislik terimleriyle GTAMulti ahalisine hava mı atayım... İş.. eskiden bu sektördeydim. Şimdi de bir butik kafe açsam iyi olur aslında

kafe sarar da butik sıktı

Hayırlısı..

[Amper]

bence iki tarafın da haklı olduğu yerler var, baştan okudum şakasız. ancak @Krips Je, burada söylediğin şeylerin değerli olabilmesi için net metrikler paylaşman gerekiyor bence. bu alanda daha bilgili biri metrikleri daha iyi söyleyecektir ama loss değerlerini görmek isterim en azından, ortalama bir sunucuda olacak oyuncu sayısıyla. (ve realistik ortalama bir sunucunun içerebileceği trafiği yaratmalı içinde çalışan oyun modu)

ben network uzmanı değilim ama sadece teknik terimleri arka arkaya dizip birbirinizi ezmeye çalıştığınız bir tartışma ortamı çok mantıklı değil ve şahsen ben bu konuyu ilk okuduğumda oyuncu sayısının 50'yi geçeceğini pek düşünmemiştim. "çok modern teknolojiler kullanılacak bir proje" diye düşünmemiştim. gerçekten scale ettiniz mi kendi kafanızda projeyi? aktif trafiği sıradan bir web uygulamasına göre bile düşük kalır gibi geliyor bana.

ayrıca modding konusuyla ilgili ifşalama hoş olmamış. şeytan şirketin politikasını desteklemeyin yahu

[Krips Je]

@spirit Teknik terimlerle dolu, ukalalıkla süslenmiş ama pratikten tamamen uzak bir metin yazmışsın. RFC ezberleyip, whitepaper okuyarak gerçek dünya sistem mimarileri üzerine hüküm veremezsin.

eNet tercihi çağın gerisinde falan değil. 50+ farklı senaryoda, yüksek paket kaybı ve jitter altında yapılan testlerde en stabil sonucu verdiği için kullanıldı. Raknet ya da Lidgren gibi daha featurerich görünen alternatifler özellikle yoğun trafik altında daha fazla bellek tüketimi ve delay oluşturuyor. Quiche gibi QUIC tabanlı çözümler ise oyun içi delay toleransı için değil, veri güvenliği odaklı. Bunuda öğrenmiş oldun    yani teknik gerçeklik senin masa başı teorilerinden biraz daha farklı işliyor.

Json api tercihi debug kolaylığı, erişilebilirlik ve 3rd party sistemlere entegrasyon önceliğiyle yapıldı yani gRPC elbette daha verimli ama bizim önceliğimiz sıkıştırmadan çok geliştirilebilirlik ve erişim kolaylığıydı. Bu arada, Json api dışa açık değil. Kapsülleme içeride. Dış servisler erişemez. Bunuda öğrenmiş oldun.

Lifecycle konusu da process restart değil. Her instance kendi başına decision alabilir, izolasyon yapabilir, başka sunucularla senkronize olabilir. Her sunucu bağımsız çalışır lafı yazılımsal olarak sadece bir while[true] değil, kendi kaynaklarını yöneten izole birimlerdir. Yani microservice değil ama ona yakın mantıkla işliyor.

Bağımsız mimari dediğimiz şey, GTA 4 ün kendi client senkronizasyon sistemini hooklamayıp, sıfırdan UDP tabanlı senkron bir protokol kurmak. Yani mod değil. DLL injection ya da memory patching yöntemleri modifikasyon aracı olabilir ama biz, oyunun orijinal sistemine override yapmıyoruz. Ayrı bir bağlantı katmanı kuruyoruz. Bu da teknik olarak mod değil, harici multiplayer framework.

Son olarak da teoride çok şey yazmak kolay. Ama şu an o sistem çalışıyor. Oyuncu bağlanıyor, araç sürüyor, dünya senkronize oluyor. Yani senin sayfalarca yazdığın şeyi biz çoktan uyguladık. Sadece senin bilgin dışında gelişmiş olması, onun yanlış olduğunu göstermez.

Sen teknik konuşmaya devam et, biz de yazmaya ve test etmeye devam edelim. Sayemde çok şey öğrendin baksan. 

Yuh!!! :(
Gerçekten, teknik bir mimari eleştirisini "whitepaper ezberlemekle" geçiştirmeye çalışmak, aslında ne kadar savunmasız olduğunun ilk belirtisi değil mi pre-middleware specialist ağabey! Üstünkörü bir benchmark anekdotu atarak eNet tercihini rasyonalize etmek, veriyle değil "kendi yazdım, mecbur savunayım" dürtüsüyle hareket ettiğini açıkça gösteriyor yani, haberin ola. "50+ farklı senaryo", "yüksek jitter", "stabilite", kusura bakma ama bu açıklamalar, modern oyun mühendisliğinde "anlamlı" sayılmaz. Çünkü hangi tür jitter altında ne tür trafik modellerinde hangi parametrelerle test ettiğini belirtmeden söylenen her şey pazarlama kelimesinden öteye geçmez. IVMP'nin R* sunucularını lağvettikten sonra yaptığı zayıf reklam hilelerine benziyor. TCP'de bile "stabilite" diye tabir edilen şey UDP tabanlı oyun protokollerinde "false positive safety" ile cezalandırılır. eNet gibi 20 yıl önce yazılmış bir kütüphane, retransmission politikasında hala stop-and-wait hybrid kullanırken, sen çıkıp 2025'te bunu "en stabil" diye yutturuyorsan, ya konuyu bilmiyorsun ya da işine öyle geliyor. Raknet delay oluşturuyor, Lidgren bellek tüketiyor. Evet, çünkü onlar oyun içi davranışı stabilize etmeye çalışan middle-layer çözümler. Zaten "hafif" olması gereken UDP üzerine yazılan bu sistemlerin, belirli layer'lar eklemesi sistematik bir tradeoff. eNet'in "lightweight" olması bir meziyet değil, çünkü hiçbir şey yapmıyor. Prediction? Yok. Fragmentation compensation? Yok. NAT hole punching? Primitive. Senin tercihinin "light" olması senin çözümünün "iyi" olduğu anlamına gelmiyor. Üzgünüm, lightweight != rightweight. Json API erişilebilirlik için tercih edildi falan demişsin. Allah... Buna da artık "aha bir start-up cümlesi daha" diyeceğim. JSON'un debug kolaylığı diye savunduğun şey, latency-sensitive bir real-time sistemde CPU-bound dönüşüm overhead'i yaratıyor. Yani senin geliştiriciye "kolaylık" diye sunduğun şey, oyuncuya "gecikme" olarak dönüyor. Geliştirilebilirlik falan diyorsun ama ortada geliştirilebilecek bir event registry bile yok. O "kapsülleme içeride" cümlesi de komik, çünkü sen dış dünyaya "JSON API" tanımı yaptıysan, ister istemez dış sistem uyumluluğu, schema güvenliği, contract binding gibi dertlerin var. Şu an "değil" diyorsun, ama günün sonunda o API dışa açılacak. Aksi halde "API" değil, sadece lokal bir dispatchEvent() handler'ı olur. Lifecycle process restart değil, izole birimler.. Evet, e madem öyle sandboxing mi var (ikinciye sordum he, değerimi bil. tekrar cevaplamazsan var diyim)? Resource cgroup izolasyonu mu yapıyorsun? Yoksa senin "izolasyon" dediğin şey port range'leri ayırıp "her biri kendi portunda çalışıyor abi ya" demek mi? Stateless bir yapıda instance başlatmak "izolasyon" değil, "bağımsız çalıştırma". Mesela process crash sonrası persist edilen bir state var mı? Konsistent shared state replication? Var mı consensus algorithm ile senkronizasyon (Raft, Paxos)? Yoksa "birbirinden haber alıyorlar" mı? Kusura bakma ama bu tam olarak distributed sistem sandığını centralized config propagation yapmaktan ibaret. Override yapmıyoz, framework falan filan. Evet, Orange:MP hatta, değil mi? Şimdi işin en komik kısmına geldik. Hooklamadığın sistemde senkronizasyon kuruyorsan, bu doğrudan memory layer dışından replicate etmeye çalışma anlamına gelir. Yani senin client, oyunun kendi tick sistemine paralel bir layer yaratıyor. Ve bu layer native clock cycle ile uyumlu değilse, her zaman ghost input, unsynced entity ve visual de-sync üretir. Eğer "mod değil" diyorsan, oyunun kendi koduna erişmiyorsan, asla tam bir eşleşme sağlayamazsın. Ve "tam bir eşleşme" olmadan da bu, real-time multiplayer framework değil; sadece gecikmeli bir kontrol proxy'sidir.

Son olarak,

> Sen teknik konuş, biz çalıştırıyoruz.

Evet. Ama işte mesele de burada başlıyor. Çalıştırmak kolay, çalıştırdığın şeyi doğru yapmak mesele. Rust'la yazsan ne olur, eNet'i gömüp stabil desen ne olur? Mimaride temel problemler varsa, sistem değil tabela inşa ediyorsun. Ve evet, çalışıyor olabilir. Ama nerenin standardına göre çalışıyor? 2006'daki SA-MP kafasına göre mi, yoksa 2025'in ECS, deterministic rollback ve delta state compression çağına göre mi? Senin yaptığın şey, bir çölde yürüyüp ısıya alışınca "burası yaşam alanı" demek gibi. Oysa çölde yaşanmaz, sadece hayatta kalınır. Mühendislik de "ayağa kalktı" diye bitmez. Doğru ayağa kalktı mı, asıl soru bu. Ha tamam ya, boşversene; her şeyi yaptın, Meta'dan RakNet'in NCIP+ versiyonunu falan aldın, ara yazılım derdi falan, hiçbir şey yok. Yağ gibi akıp gidiyor, MTA:SA Blue'nun en stabil versiyonun da daha iyi. RevIVal dedikleri toplulukta bile 100 kişi anca yılda bir toplanıp GTA IV minigame'i oynuyor. Sen bu client'i kime sunuyorsun? Üç hafta sonra kaybolacak altmış oyuncuya mı? Yol yakınken vazgeç, çok istiyorsan böyle laga luga client işlerini RAGE için GTA VI projesinde project process manager ol. Cfx.Re ile rekabet edersiniz, en azından orada altmış değil de yüz binlerce oyuncu olacak, milyonlar hatta.

"sayemde çok şey öğrendin baksan"
evet ya, özellikle UDP'yi JSON'la sarınca hızlanıyor sanmak kısmı çok ufuk açıcıydı. 2004'te yazılmış bir kütüphaneyi 2025 mimarisine "bilerek" seçmek gibi ileri görüşlülüğü de ancak senin gibi birinden öğrenebilirdim. RFC değil, Reddit yorumu ezberleyenler için teknik rehberlik sağladığın için gerçekten minnettarım. Bir dahaki derste belki try-catch'in Kubernetes alternatifi olduğunu da öğreniriz senden -- sonuçta "çalışıyor" değil mi? :*


- yalnızca RFC ezberlemeyen, latency'nin ne zaman latency olduğunu bilen biri

Yazdıklarını detaylıca inceledim. Teknik seviyen belli ve konuya yüzeysel yaklaşmadığın ortada. Bazı eleştirilerin yerinde, bazı tespitlerin eksik ya da bağlam dışı, bazıları ise hala geliştirme sürecinde olduğumuz kısımlarla çakışıyor. Ben de burada sistemin temellerini inşa eden kişi olarak, tercih ettiğimiz yaklaşımları doğrudan anlatayım istedim.

eNet meselesiyle başlayalım. "2004'ten kalma bir teknoloji" demek kolay ama her teknoloji yaşıyla değil, kullanıldığı bağlamla değerlendirilir. eNet bizim nihai ağ çözümümüz değil, yalnızca UDP üstü düşük seviyeli bir transport layer olarak yer alıyor. Üzerine inşa ettiğimiz scheduler, internal paket düzeni, veri öncelikleme sistemi ve latency-aware dispatch katmanı doğrudan bizim tarafımızdan yazıldı. Yani eNet bizim mimaride yalnızca en alt kabuk geri kalan kısımlar eNeti çoktan aşmış durumda bu yüzden daha ağır çözümler olan RakNet ya da Lidgren gibi sistemler yerine, daha hafif ama kontrol edilebilir bir yapı tercih edildi. Kendi çözümünü yazmak tekerleği yeniden icat etmek değil; neyi neden değiştirdiğini bilerek, elindeki altyapıyı yeniden şekillendirmektir.

"Bağımsız .exe çalıştırmak" meselesi için "teknik borç" tanımı fazla iddialı. Asıl amaç merkezi değil, yatayda ölçeklenebilir bir instance yönetimi kurmaktı. Evet, şu anda container tabanlı dağıtım Docker, Nomad, vb vb.. için doğrudan bir destek sunulmuyor ancak sistemin modüler mimarisi bu geçişi mümkün kılacak şekilde yapılandırıldı. Hatta modül motorunun iç yapısı da buna göre yeniden yazılıyor. Hot-reload, script izolasyonu, sandboxing gibi unsurlar şu anda aktif geliştirme başlıkları. Yani sistem olduğu yerde kalmayacak. Şu anki formu, temel sistemin stabilitesini ispatlamak için.

JSON API üzerinden vurmuşsun, doğal olarak. Haklı olduğun yer var. Performans kritik bir sistemde plaintext format ideal değil. Ancak JSON bu aşamada developer-facing bir çözüm olarak burada. CLI, dashboard ve webhook sistemleri için hızlıca adapte edilebilir ve okunabilir olması önceliklendirildi. Sistem içerisindeki ağ iletişimi ise JSON değil orası zaten binary layera taşınmış durumda. Yani dış API JSON, iç katman binary. Bu fark kritik.

"Her sunucunun kendi lifecycle ı vardır" cümlesiyle anlatmak istediğimiz şey, instance ların merkezi bir dependencye bağlı olmadan kendi yaşam döngülerini yöneten yapılar olması. Bu sadece try-catch değil, aynı zamanda kendi configi, event busı, local modül kontrolü ve mesaj kuyruğu olan micro-node mantığı. Crash sonrası kendi kendini ayağa kaldırma, log toplanması, modül yeniden çağırımı gibi mekanizmalar zaten var. Henüz orkestrasyon ortamlarına entegre edilmedi, ama kod seviyesi buna uygun inşa edildi.

Senin öne sürdüğün delta-compression, prediction modeli, latency hiding gibi advanced networking konularına gelirsek: Bunlar teoride çok şey vaat eder ama sahada büyük maliyet üretir. Bizim sistemde bunların bazılarına dair denemeler yapılmış durumda örnek;

entity snapshot,
tick history,
visual smoothing

gibi gibi alanlarda belirli çözümler var. Ancak bunlar hala test aşamasında ve productiona girmiş değil. Amacımız, bu tür optimizasyonları sadece şık görünmek için değil, gerçekten etkili olduklarında entegre etmek. Yani buradaki tercihimiz az ama sağlam.

Modül sistemiyle ilgili soru açık Lua mı, JS mi, yoksa C API binding mi? Şu an için gömülü bir script engine test ediliyor henüz final değil. Planlanan şey, dıştan yüklenebilir plugin mimarisi. Yani DLL seviyesinde API binding de dahil. Ancak bu da parça parça açılacak çünkü sandbox güvenliği ve kaynak izolasyonu gibi başlıklar daha öncelikli.

Son olarak mod olup olmadığımız meselesi. Teknik olarak, oyun içeriğiyle memory-level etkileşime girdiğiniz her yapı bir tür modifikasyon sayılır doğru. Ancak bizim yaklaşımımız, biz oyunun mantığına değil, çevresine etki ediyoruz. Client tarafında injection ya da memory patching gibi alanlara giriyoruz, evet, ama bu müdahaleler engine mantığını değil, client-server iletişimini hedefliyor. Yani biz kendimizi bir mod platformu değil, bir bağımsız multiplayer sistemi olarak tanımlıyoruz. Hukuki anlamda tabii ki gri alandayız bu işin doğasında var.

Eleştirilerinin altında ciddi bir birikim olduğunu inkar etmiyorum. Teknik olarak kafa yormuşsun. Bazı noktaları abartılı bulsam da, çoğunun ardında anlamlı bir perspektif var. Yazdığın şeyler doğrudan dikkate alındı, bazıları iç toplantılarda da gündem oldu zaten.

Ama şunu da eklemem gerekir ki, biz bu projeyi her şeyi baştan yazmak için değil eksik olanı tamamlamak için inşa ediyoruz. Her şey kusursuz değil. Ama her tercih bilinçli.

[Krips Je]

bence iki tarafın da haklı olduğu yerler var, baştan okudum şakasız. ancak @Krips Je, burada söylediğin şeylerin değerli olabilmesi için net metrikler paylaşman gerekiyor bence. bu alanda daha bilgili biri metrikleri daha iyi söyleyecektir ama loss değerlerini görmek isterim en azından, ortalama bir sunucuda olacak oyuncu sayısıyla. (ve realistik ortalama bir sunucunun içerebileceği trafiği yaratmalı içinde çalışan oyun modu)

ben network uzmanı değilim ama sadece teknik terimleri arka arkaya dizip birbirinizi ezmeye çalıştığınız bir tartışma ortamı çok mantıklı değil ve şahsen ben bu konuyu ilk okuduğumda oyuncu sayısının 50'yi geçeceğini pek düşünmemiştim. "çok modern teknolojiler kullanılacak bir proje" diye düşünmemiştim. gerçekten scale ettiniz mi kendi kafanızda projeyi? aktif trafiği sıradan bir web uygulamasına göre bile düşük kalır gibi geliyor bana.

ayrıca modding konusuyla ilgili ifşalama hoş olmamış. şeytan şirketin politikasını desteklemeyin yahu

Selam, mesajını okudum dostum. içtenlikle yazdığın belli, o yüzden aynı samimiyetle cevap vereyim istedim.

Öncelikle haklısın, bu tür konular sadece teknik terimleri art arda dizerek değil, bağlam ve kullanım senaryolarıyla birlikte konuşulmalı. Burada anlatılmak istenen şeyin özünü, yani aktif trafik içinde oyun içi senaryoları çalıştırabilecek gerçekçi bir sistem kurmak fikrini doğru yakalamışsın.

Oyuncu sayısı konusuna gelince evet, başlangıçta ortalama sunucu hedefiyle ilerliyoruz. Bu, bizim için 40-60 eş zamanlı oyuncu civarında bir yük anlamına geliyor. Elbette 50 yi geçecek mi? sorusu ciddi çünkü bu tarz sistemlerde eş zamanlılık arttıkça yalnızca ağ değil, script motoru, veri senkronizasyonu, entity yönetimi gibi sistemler de logaritmik şekilde zorlanıyor. Bizim amacımız da zaten bu sınırı hem teknik olarak hem de geliştirici dostu biçimde yukarı taşımak.

Gerçekten scale ettiniz mi? sorusuna gelirsek. Şu an için dikey ölçekleme yani tek makinada çekirdek kullanımına dayalı + modül izolasyonlu tasarımımız var. Yani her modül kendi lifecycleı ile çalışıyor. Bazıları multi-threaded, bazıları thread-safe tasarlandı. Şimdi sırada yatayda bölünebilir, hatta farklı fiziksel sunuculara dağıtılabilir modül kümeleri üzerine testler var. Kısacası ölçeklenebilirlik bizim roadmapimizin tam ortasında.

Modern teknolojiler kullanılacak bir proje gibi düşünmemiştim demen de anlaşılır çünkü biz görselde, dış katmanda, ön yüzde bling-bling şeyler sunmuyoruz. Ama alt katmanda işler değişiyor mesela low-level UDP optimizasyonları, aktör tabanlı concurrency, modüler runtime engine, plugin bridge katmanı, hepsi halihazırda yürürlükte ya da geliştirme aşamasında. Hedef, sadece göze değil, geliştiricinin beynine hitap eden bir şey inşa etmekti.

Modding konusundaki fikrine de katılıyorum. Bu işin politik tarafları her zaman gri kalıyor çünkü bizim hedefimiz şirket politikasına değil, geliştirici özgürlüğüne destek olmak. Ne bir oyunun içine sızmaya çalışıyoruz, ne de resmi olmayan açıkları zorlayarak var olmaya. Biz sadece o oyunun eksik bıraktığı alanı, saygı çerçevesinde tamamlıyoruz diyebilirim.

Yorumun için gerçekten teşekkür ederim. Eleştiri değil, katkı gibi geldi. Böyle yazıldığında her kelime gerçekten değerli oluyor.

[Impeccable]

En sevdiğim GTA oyunuyla alakalı bu proje umarım başarılı olur, bu arada iki kullanıcının teknik bilgilerine hayran kaldım eleştirel ve konuya hakim yorumlara ve eleştiriyi kaldırabilen insanlara saygım sonsuz, yolunuz açık olsun umarım istediğiniz yerlere ulaşır proje.

[Krozfayer]

Farklı şeyler görmek güzel, başarılar.

[Krips Je]

En sevdiğim GTA oyunuyla alakalı bu proje umarım başarılı olur, bu arada iki kullanıcının teknik bilgilerine hayran kaldım eleştirel ve konuya hakim yorumlara ve eleştiriyi kaldırabilen insanlara saygım sonsuz, yolunuz açık olsun umarım istediğiniz yerlere ulaşır proje.

Farklı şeyler görmek güzel, başarılar.

[mtb]

ne anlatıyonuz olm gptye özet geç dedim o bile bişey anlamadı

basarilar btw

[laéx]

eNet kullanmak tabii ki de günümüzde eski bir teknoloji sayılsa da, düşük seviyeli projelerde hâlâ kullanılıyor. Tabii ki de kapsamlı bir proje yapılacaksa, eNet teknolojisi artık eskimiş sayılır. Güvenliğine kadar her şeyi geliştiricilerin yapması gerekiyor ve bu da uzun ve uğraştırıcı bir iştir.

Mantıklı mı?
Eğer ağ programlama yeteneğine güveniyorsan, evet, altyapı kurmak teknik olarak mümkün ve performanslıdır. Ancak eNet ile bir server-side geliştirmek, hazır altyapı kullanmadan ya da geniş bir network ekibin yoksa uğraştırıcı ve uzun zaman alacaktır.

Şunu unutmamak lazım: UDP tabanlı projeler her zaman düşük gecikme ve daha hızlı paket alışverişi sağlar.
Dezavantajları da mevcut tabii ki; UDP'nin doğası gereği güvensiz olması, günümüzdeki modern network yapıları gereği güvenliğin en az performans kadar önemli olmasını beraberinde getiriyor.

eNet, WebSocket ve QUIC gibi modern protokolleri, eski olması sebebiyle sağlayamıyor. Ayrıca Wi-Fi gibi bağlantılarda eNet'in hata toleransı zayıftır. Günümüzde, güvenlik ve performans amacıyla daha güncel ve verimli networking kütüphanelerine yönelmek daha mantıklı olacaktır.

Umarım bizi yanıltırsınız, başarılarınızın devamını diliyorum.

Not: Bu yorumda tamamen kendi düşüncelerimi belirttim network öğrencisi olarak. Herhangi bir şekilde projeyi baltalamak gibi bir niyetim bulunmamaktadır, aksine desteklerimi iletiyorum.

[M A T I Z]

Sırf bu sebeple bile Gta 4'ü tekrar indirebilirim.. (:

[Krips Je]

eNet kullanmak tabii ki de günümüzde eski bir teknoloji sayılsa da, düşük seviyeli projelerde hâlâ kullanılıyor. Tabii ki de kapsamlı bir proje yapılacaksa, eNet teknolojisi artık eskimiş sayılır. Güvenliğine kadar her şeyi geliştiricilerin yapması gerekiyor ve bu da uzun ve uğraştırıcı bir iştir.

Mantıklı mı?
Eğer ağ programlama yeteneğine güveniyorsan, evet, altyapı kurmak teknik olarak mümkün ve performanslıdır. Ancak eNet ile bir server-side geliştirmek, hazır altyapı kullanmadan ya da geniş bir network ekibin yoksa uğraştırıcı ve uzun zaman alacaktır.

Şunu unutmamak lazım: UDP tabanlı projeler her zaman düşük gecikme ve daha hızlı paket alışverişi sağlar.
Dezavantajları da mevcut tabii ki; UDP'nin doğası gereği güvensiz olması, günümüzdeki modern network yapıları gereği güvenliğin en az performans kadar önemli olmasını beraberinde getiriyor.

eNet, WebSocket ve QUIC gibi modern protokolleri, eski olması sebebiyle sağlayamıyor. Ayrıca Wi-Fi gibi bağlantılarda eNet'in hata toleransı zayıftır. Günümüzde, güvenlik ve performans amacıyla daha güncel ve verimli networking kütüphanelerine yönelmek daha mantıklı olacaktır.

Umarım bizi yanıltırsınız, başarılarınızın devamını diliyorum.

Not: Bu yorumda tamamen kendi düşüncelerimi belirttim network öğrencisi olarak. Herhangi bir şekilde projeyi baltalamak gibi bir niyetim bulunmamaktadır, aksine desteklerimi iletiyorum.

Sırf bu sebeple bile Gta 4'ü tekrar indirebilirim.. (: