The future of TNL?
by Kirby Zhang · in Torque Game Engine · 07/07/2007 (9:53 pm) · 1 replies
I have had a solid experience using this library. Just a couple of wish items:
- better documentation of many key concepts such as memory management, method binding, and the delivery guarantees (I had a problem where ordered packets were holding up unordered, unguaranteed packets!)
- blocking call semantics. The client should be able to make a blocking network call except during ProcessNetEvents
- multithreaded connections. By running connections from a thread pool, a TNL server can make use of multi-core cpus.
Does anyone have experience with networking under XNA? Is there a need for c# port of TNL?
Kirby
- better documentation of many key concepts such as memory management, method binding, and the delivery guarantees (I had a problem where ordered packets were holding up unordered, unguaranteed packets!)
- blocking call semantics. The client should be able to make a blocking network call except during ProcessNetEvents
- multithreaded connections. By running connections from a thread pool, a TNL server can make use of multi-core cpus.
Does anyone have experience with networking under XNA? Is there a need for c# port of TNL?
Kirby
About the author
Torque 3D Owner Stephen Zepp
Currently, the major downside of programming networking into XNA is that XNA has two different delivery targets: Windows machines, and XB360.
For Windows machines, you can use any of the .NET 2.0 capabilities, which include some pretty strong networking capability.
For XB360 however, it only allows for the compact framework, so anything that uses .NET 2.0 can't be deployed to a 360.
We're basically in a "standby on networking" mode with XNA (TorqueX specifically) until Microsoft can define their GSE-XNA specific cross-hardware architecture, so we can kill both birds with one networking lib instead of focusing on a windows-dependent implementation.