opentnl-general Mailing List for Torque Network Library (Page 8)
Brought to you by:
mark_frohnmayer,
s_alanet
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
(39) |
May
(34) |
Jun
(5) |
Jul
(5) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(2) |
Feb
(8) |
Mar
(18) |
Apr
(6) |
May
(12) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(8) |
Nov
(1) |
Dec
|
2006 |
Jan
(5) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(1) |
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
2009 |
Jan
(24) |
Feb
(2) |
Mar
(2) |
Apr
(26) |
May
(75) |
Jun
(85) |
Jul
(46) |
Aug
(18) |
Sep
(14) |
Oct
(24) |
Nov
(8) |
Dec
(3) |
2010 |
Jan
(1) |
Feb
(1) |
Mar
(40) |
Apr
(57) |
May
(80) |
Jun
(58) |
Jul
(45) |
Aug
(49) |
Sep
(28) |
Oct
(6) |
Nov
(1) |
Dec
(3) |
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(10) |
Jul
(7) |
Aug
(7) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(13) |
Sep
(8) |
Oct
(4) |
Nov
|
Dec
(1) |
2013 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(14) |
Sep
(44) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2014 |
Jan
(4) |
Feb
(42) |
Mar
(3) |
Apr
(1) |
May
(7) |
Jun
(5) |
Jul
(14) |
Aug
(2) |
Sep
(2) |
Oct
(54) |
Nov
(43) |
Dec
(36) |
2015 |
Jan
(48) |
Feb
(64) |
Mar
(52) |
Apr
(24) |
May
(52) |
Jun
(60) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
(12) |
2016 |
Jan
(17) |
Feb
(2) |
Mar
(6) |
Apr
|
May
(66) |
Jun
(40) |
Jul
(51) |
Aug
(42) |
Sep
(24) |
Oct
(10) |
Nov
(46) |
Dec
(7) |
2017 |
Jan
(14) |
Feb
(11) |
Mar
(2) |
Apr
(1) |
May
(31) |
Jun
(8) |
Jul
(10) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Jeff D. <jd...@cs...> - 2005-05-01 01:06:34
|
Mark Frohnmayer wrote: > All NetConnections on a NetInterface share the same port. To accurately > determine the port for a NetInterface, you should use the NetInterface's > getSocket() method, and then call getBoundAddress on the socket. This > will give you at least an accurate port. The address may be > Address::Any if it wasn't specified which hardware interface the > NetInterface should bind to. So you can use the combination of > Socket::getInterfaceAddresses and > NetInterface::getSocket().getBoundAddress() to determine the port. |
From: Mark F. <ma...@ga...> - 2005-04-30 23:26:20
|
>Ok, thanks, but that doesn't give the port, which wouldn't >distinguish between possibly many connections from the same >machine. > > All NetConnections on a NetInterface share the same port. To accurately determine the port for a NetInterface, you should use the NetInterface's getSocket() method, and then call getBoundAddress on the socket. This will give you at least an accurate port. The address may be Address::Any if it wasn't specified which hardware interface the NetInterface should bind to. So you can use the combination of Socket::getInterfaceAddresses and NetInterface::getSocket().getBoundAddress() to determine the port. |
From: Jeff D. <jd...@cs...> - 2005-04-30 21:58:22
|
> Jeff Donner wrote: >> NetConnection::getNetAddress() and NetConnection::getNetAddressString() >> both refer to the remote side; is there an easy way to >> get the address (IP:port) of /this/ side? Mark Frohnmayer wrote: > The Socket::getInterfaceAddresses function gets the list of > locally bindable addresses. Ok, thanks, but that doesn't give the port, which wouldn't distinguish between possibly many connections from the same machine. I've done the following and it works for what I need but, I'm a little surprised the information is not incorporated somehow into NetConnection. Oh well: From the example TestNetInterface::handleInfoPacket(...), (with couts added) in the client part ('this' end): cout << "ADDRESSES:" << endl; TNL::Vector<TNL::Address> addresses; TNL::Socket::getInterfaceAddresses(&addresses); for (int i = 0; i < addresses.size(); ++i) { cout << "address: " << addresses[i].toString() << endl; } TNL::Address b = getFirstBoundInterfaceAddress(); cout << "FIRST BOUND: " << b.toString() << endl; output: ADDRESSES: address: IP:192.168.0.8:0 FIRST BOUND: IP:192.168.0.8:33513 From the function, in the server part upon connection (remote end): cout << "CLIENT ADDRESS: " << address.toString() << endl; output: CLIENT ADDRESS: IP:192.168.0.8:33513 Of course, this probably wouldn't work if there were more than one connection to the server (which connection would be the first?) but it works for what I need. Thanks again, Jeff |
From: Mark F. <ma...@ga...> - 2005-04-30 19:44:05
|
Hey Jeff, The Socket::getInterfaceAddresses function gets the list of locally bindable addresses. - Mark Jeff Donner wrote: >Hi, > > NetConnection::getNetAddress() and NetConnection::getNetAddressString() >both refer to the remote side; is there an easy way to >get the address (IP:port) of /this/ side? > >Thanks! > > >------------------------------------------------------- >This SF.Net email is sponsored by: NEC IT Guy Games. >Get your fingers limbered up and give it your best shot. 4 great events, 4 >opportunities to win big! Highest score wins.NEC IT Guy Games. Play to >win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Jeff D. <jd...@cs...> - 2005-04-30 19:28:27
|
Hi, NetConnection::getNetAddress() and NetConnection::getNetAddressString() both refer to the remote side; is there an easy way to get the address (IP:port) of /this/ side? Thanks! |
From: Ville A. B. <vbe...@cc...> - 2005-04-19 16:32:41
|
Hi, I would like to use a BitStream as an RPC parameter. Since the OpenTNL RPCs already accept ByteBuffer parameters, I guess this should be possible, but what would be the safest way of doing it? On the calling side I can use void Send(XXX &myobject) { BitStream s; myobject.Write(s); connection->rpcSend(s); } but what about the receiving side? I was thinking of something like TNL_IMPLEMENT_RPC(MyConnection, rpcSend, (ByteBufferPtr buf), (buf), NetClassGroupGameMask, RPCGuaranteedOrdered, RPCDirClientToServer, 0) { BitStream s(buf->getBuffer(), buf->getBufferSize()); XXX myobject; myobject.Read(s); ... } Does this approach work, or am I completely on a wrong track here? Thanks in advance, Ville -- Ville Bergholm |
From: Bren L. <bl...@te...> - 2005-04-02 21:47:17
|
Ah, sorry for the dupe, I just joined the list. TNL::StringPtr did fix the problem. :) > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] On=20 > Behalf Of Ville Axel Bergholm > Sent: Wednesday, March 30, 2005 2:51 AM > To: ope...@li... > Subject: Re: [Opentnl-general] TNL_IMPLEMENT_RPC Build Error >=20 >=20 > On Wed, 30 Mar 2005, Bren wrote: >=20 > > I=B4m having a problem building a GhostConnection subclass. >=20 > > // declare the client to server message > > TNL_DECLARE_RPC(rpcMessageClientToServer, (const char > > *theMessageString)); >=20 > > TNL_IMPLEMENT_RPC(NetworkConnection, > > rpcMessageClientToServer, > > (const char * messageString), > > (messageString), > > TNL::NetClassGroupGameMask, > > TNL::RPCGuaranteedOrdered, > > TNL::RPCDirClientToServer, > > 0) >=20 > > The build error: > > > > d:\Project\tnl\tnl\tnlMethodDispatch.h(85) : error C2664: =B4bool > > TNL::BitStream::read(TNL::ByteBuffer *)=B4 : cannot convert=20 > parameter 1 > > from =B4const char ** =B4 to =B4TNL::ByteBuffer *=B4 Types=20 > pointed to are > > unrelated; conversion requires reinterpret_cast, C-style cast or > > function-style cast >=20 > > Any suggestions? >=20 > If you use OpenTNL 1.5.0, your problem is the same one that I > presented=20 > here a few days ago. Replace the const char* with a TNL::StringPtr. >=20 >=20 > Cheers, > Ville >=20 > --=20 > Ville Bergholm | vbe...@cc... | > http://www.hut.fi/u/vberghol/ >=20 > mobile =20 > +358-44-5722802 Lehtisaarentie 6 G > telephone +358-9-4582738 00340 Helsinki, Finland >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. Discover which products truly live up to the=20 > hype. Start reading now.=20 > http://ads.osdn.com/?ad_ide95&alloc_id=14396> &op=3Dick >=20 > _______________________________________________ >=20 > Opentnl-general mailing list Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general >=20 --=20 I am using the free version of SPAMfighter for private users. It has removed 28798 spam emails to date. Paying users do not have this message in their emails. Try www.SPAMfighter.com for free now! |
From: Ville A. B. <vbe...@cc...> - 2005-03-30 10:51:25
|
On Wed, 30 Mar 2005, Bren wrote: > I=B4m having a problem building a GhostConnection subclass. > // declare the client to server message > TNL_DECLARE_RPC(rpcMessageClientToServer, (const char > *theMessageString)); > TNL_IMPLEMENT_RPC(NetworkConnection, > rpcMessageClientToServer, > (const char * messageString), > (messageString), > TNL::NetClassGroupGameMask, > TNL::RPCGuaranteedOrdered, > TNL::RPCDirClientToServer, > 0) > The build error: > > d:\Project\tnl\tnl\tnlMethodDispatch.h(85) : error C2664: =B4bool > TNL::BitStream::read(TNL::ByteBuffer *)=B4 : cannot convert parameter 1 > from =B4const char ** =B4 to =B4TNL::ByteBuffer *=B4 Types point= ed to are > unrelated; conversion requires reinterpret_cast, C-style cast or > function-style cast > Any suggestions? If you use OpenTNL 1.5.0, your problem is the same one that I presented=20 here a few days ago. Replace the const char* with a TNL::StringPtr. Cheers, Ville --=20 Ville Bergholm | vbe...@cc... | http://www.hut.fi/u/vberghol= / mobile +358-44-5722802 Lehtisaarentie 6 G telephone +358-9-4582738 00340 Helsinki, Finland |
From: Bren <br...@sa...> - 2005-03-30 09:40:05
|
I=B4m having a problem building a GhostConnection subclass. NetworkConnection.h #ifndef _NETWORKCONNECTION_H_ #define _NETWORKCONNECTION_H_ class NetworkConnection : public TNL::GhostConnection { typedef TNL::GhostConnection Parent; public: TNL_DECLARE_NETCONNECTION(NetworkConnection); // declare the client to server message TNL_DECLARE_RPC(rpcMessageClientToServer, (const char *theMessageString)); // declare the server to client message TNL_DECLARE_RPC(rpcMessageServerToClient, (const char *theMessageString)); }; #endif NetworkConnection.cpp #include "NetworkIncludes.h" TNL_IMPLEMENT_NETCONNECTION(NetworkConnection, TNL::NetClassGroupGame, true); TNL_IMPLEMENT_RPC(NetworkConnection,=20 rpcMessageClientToServer,=20 (const char * messageString),=20 (messageString), TNL::NetClassGroupGameMask,=20 TNL::RPCGuaranteedOrdered,=20 TNL::RPCDirClientToServer,=20 0) { // display the message the client sent printf("Got message from client: %s\n", messageString); // send a hello world back to the client. rpcMessageServerToClient("Hello, World!"); } TNL_IMPLEMENT_RPC(NetworkConnection,=20 rpcMessageServerToClient,=20 (const char * messageString), (messageString), TNL::NetClassGroupGameMask,=20 TNL::RPCGuaranteedOrdered,=20 TNL::RPCDirServerToClient,=20 0) { // display the message the server sent printf("Got a message from server: %s\n", messageString); // once the client has heard back from the server, it should quit. // gQuit =3D true; } The build error: d:\Project\tnl\tnl\tnlMethodDispatch.h(85) : error C2664: =B4bool TNL::BitStream::read(TNL::ByteBuffer *)=B4 : cannot convert parameter 1 from =B4const char ** =B4 to =B4TNL::ByteBuffer *=B4 Types = pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast This is based on the Hello World sample, but changed from EventConnection to GhostConnection. I poured through the TNLTest source and didn't see any significant differences. Any suggestions? --=20 I am using the free version of SPAMfighter for private users. It has removed 28057 spam emails to date. Paying users do not have this message in their emails. Try www.SPAMfighter.com for free now! |
From: Mark F. <ma...@ga...> - 2005-03-24 00:37:29
|
Yes. You have to use the StringPtr type with the new RPC code. > Have you also changed the RPC system so that you cannot use c-strings > as RPC arguments anymore? > > I have an RPC method with the parameter list (S8 from, S8 to, const > char *msg). > I changed the implementation macro as explained above. > This is what I get when compiling (using OpenTNL 1.5.0 headers): > > > g++ -c -O -Wall -mwindows -D__WIN32__ -DSDL -DHWRENDER -I../include > n_connection.cpp -o ../objs/n_connection.o > ../include/tnl/tnlMethodDispatch.h: In function `void > Types::read(TNL::BitStream&, T*) [with T = const char*]': > ../include/tnl/tnlMethodDispatch.h:234: instantiated from `void > TNL::FunctorDecl<void (T::*)(A, B, C)>::read(TNL::BitStream&) [with T > = LConnection, A = signed char, B = signed char, C = const char*]' > ../include/g_pawn.h:177: instantiated from here > ../include/tnl/tnlMethodDispatch.h:85: no matching function for call to ` > TNL::BitStream::read(const char**&)' > ../include/tnl/tnlBitStream.h:211: candidates are: bool > TNL::BitStream::read(TNL::ByteBuffer*) > ../include/tnl/tnlBitStream.h:238: bool > TNL::BitStream::read(bool*) > ../include/tnl/tnlBitStream.h:331: bool > TNL::BitStream::read(unsigned int, void*) > ../include/tnl/tnlBitStream.h:260: bool > TNL::BitStream::read(U8*) > ../include/tnl/tnlBitStream.h:261: bool > TNL::BitStream::read(S8*) > ../include/tnl/tnlBitStream.h:262: bool > TNL::BitStream::read(U16*) > ../include/tnl/tnlBitStream.h:263: bool > TNL::BitStream::read(S16*) > ../include/tnl/tnlBitStream.h:264: bool > TNL::BitStream::read(U32*) > ../include/tnl/tnlBitStream.h:265: bool > TNL::BitStream::read(S32*) > ../include/tnl/tnlBitStream.h:266: bool > TNL::BitStream::read(S64*) > ../include/tnl/tnlBitStream.h:267: bool > TNL::BitStream::read(U64*) > ../include/tnl/tnlBitStream.h:268: bool > TNL::BitStream::read(F32*) > ../include/tnl/tnlBitStream.h:269: bool > TNL::BitStream::read(F64*) |
From: Ville A. B. <vbe...@cc...> - 2005-03-23 16:42:18
|
On Tue, 22 Feb 2005, Mark Frohnmayer wrote: > The CVS repo now has a bunch of RPC-related changes in. The new > RPC/journal/ThreadQueue macros have an extra parameter which is the argument > name list -- so > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 someArg2), ...) > > becomes > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 someArg2), > (someArg1, someArg2), ...) > > The reason for this is that the functions for parsing the RPC arg lists, > marshalling and unmarshalling RPC call data and the assembly language > dispatch functions have all been removed and replaced by a template based > system. The new system is substantially more stable and extensible to new > data types. Visual C++ 6.0 is no longer a TNL supported compiler. > > I'll be updating the packages as well as the documentation over the next > while... Hi, Have you also changed the RPC system so that you cannot use c-strings as RPC arguments anymore? I have an RPC method with the parameter list (S8 from, S8 to, const char *msg). I changed the implementation macro as explained above. This is what I get when compiling (using OpenTNL 1.5.0 headers): g++ -c -O -Wall -mwindows -D__WIN32__ -DSDL -DHWRENDER -I../include n_connection.cpp -o ../objs/n_connection.o ../include/tnl/tnlMethodDispatch.h: In function `void Types::read(TNL::BitStream&, T*) [with T = const char*]': ../include/tnl/tnlMethodDispatch.h:234: instantiated from `void TNL::FunctorDecl<void (T::*)(A, B, C)>::read(TNL::BitStream&) [with T = LConnection, A = signed char, B = signed char, C = const char*]' ../include/g_pawn.h:177: instantiated from here ../include/tnl/tnlMethodDispatch.h:85: no matching function for call to ` TNL::BitStream::read(const char**&)' ../include/tnl/tnlBitStream.h:211: candidates are: bool TNL::BitStream::read(TNL::ByteBuffer*) ../include/tnl/tnlBitStream.h:238: bool TNL::BitStream::read(bool*) ../include/tnl/tnlBitStream.h:331: bool TNL::BitStream::read(unsigned int, void*) ../include/tnl/tnlBitStream.h:260: bool TNL::BitStream::read(U8*) ../include/tnl/tnlBitStream.h:261: bool TNL::BitStream::read(S8*) ../include/tnl/tnlBitStream.h:262: bool TNL::BitStream::read(U16*) ../include/tnl/tnlBitStream.h:263: bool TNL::BitStream::read(S16*) ../include/tnl/tnlBitStream.h:264: bool TNL::BitStream::read(U32*) ../include/tnl/tnlBitStream.h:265: bool TNL::BitStream::read(S32*) ../include/tnl/tnlBitStream.h:266: bool TNL::BitStream::read(S64*) ../include/tnl/tnlBitStream.h:267: bool TNL::BitStream::read(U64*) ../include/tnl/tnlBitStream.h:268: bool TNL::BitStream::read(F32*) ../include/tnl/tnlBitStream.h:269: bool TNL::BitStream::read(F64*) Regards, Ville Bergholm |
From: Jeff N. <jni...@az...> - 2005-03-18 17:43:42
|
I'm just starting with TNL. I'm really excited to be working with it - it seems to be very powerful. I'm trying to get a basic client/server working. I'm working in Visual Studio .NET 2003, using C++, using the Win32 application template, (as opposed to the console app template). I started a project yesterday morning - and I had problems making the client and server connect. After comparing the project settings between my project and the sample TestGame project, I found a setting in the C++ compiler, namely "Enable Run-Time Type Info" that was NO on my project and YES on the sample project. I set it to YES, and my applications connected. YAY! Well, today, I re-wrote the applications from scratch, to familiarize myself with the API. Again, it didn't connect. I tried the same solution (Run Type setting). This time it didn't work, and I can't get the server and client apps to connect. In my solution I have two projects, "server" and "client" - both based on win32 app (not console). I I have my own CMyTNLNetInterface, based on NetInterface, and CMyTNLGhostConnection, based on GhostConnection. For both projects: I link in tnld.lib (Im in debug phase, of course) and ws2_32.lib I define TNL_ENABLE_LOGGING and TNL_DEBUG in the preprocessor In both apps, I set a windows timer to 50ms and in the timer event, I Tick() the NetInterface, calling checkIncommingPackets() and processConnections() Server startup code looks like (port=678) Address addr(IPProtocol,Address::Any,port); m_NetInterface = new CMyTNLNetInterface(addr); m_NetInterface->setAllowsConnections(true); Client connection code looks like: (server="localhost") (port=678) Address addr1 = Address(IPProtocol,Address::Any,0); m_NetInterface = new CMyTNLNetInterface(addr1); Address addr2 = Address(server); addr2.port=port; m_GhostConnection = new CMyTNLGhostConnection; m_GhostConnection->connect(m_NetInterface,addr2); Log shows this when I start the server: 'Server.exe': Loaded (.snip) Winsock initialization succeeded. LogUDP: UDP socket created - bound to address: IP:Any:678 LogUDP: UDP socket receive buffer size set to 32768. LogUDP: UDP socket send buffer size set to 32768. LogUDP: UDP socket non-blocking IO set. Socket initialized. And adds this when I start the client and try to connect (the server and client events are mixed together) 'Client.exe': Loaded (.snip) Winsock initialization succeeded. LogUDP: UDP socket created - bound to address: IP:Any:1732 LogUDP: UDP socket receive buffer size set to 32768. LogUDP: UDP socket send buffer size set to 32768. LogUDP: UDP socket non-blocking IO set. Socket initialized. LogNetInterface: Sending Connect Challenge Request to IP:192.168.0.50:678 LogNetInterface: Received Connect Challenge Request from IP:192.168.0.50:1732 LogNetInterface: Sending Challenge Response: 2c387faf LogNetInterface: Received Challenge Response: 2c387faf Client puzzle solved in 422 ms. LogNetInterface: Sending Connect Request LogNetInterface: Received Connect Request 2c387faf LogNetInterface: Sending Connect Request LogNetInterface: Received Connect Reject - reason Puzzle LogNetInterface: Sending Connect Challenge Request to IP:192.168.0.50:678 LogNetInterface: Received Connect Challenge Request from IP:192.168.0.50:1732 LogNetInterface: Sending Challenge Response: 502963e8 LogNetInterface: Received Challenge Response: 502963e8 Client puzzle solved in 953 ms. LogNetInterface: Sending Connect Request LogNetInterface: Received Connect Request 502963e8 The program '[512] Client.exe: Native' has exited with code 0 (0x0). In the log I see that the connection attempt is being rejected. It seems that the connection puzzle challenge is not being responded to correctly. I *DO* have the onConnectTerminated function overridden on the GhostConnection, but it never gets called. Shouldn't it get called when the connection is rejected? Any ideas? Anyone? Thanks in advance! |
From: hongtao <hon...@ho...> - 2005-03-07 10:03:44
|
thank your for your response. althrough i don't studying opentnl in depth, ----- Original Message ----- From: "Allan Simonsen" <Sim...@ro...> To: <ope...@li...> Sent: Monday, March 07, 2005 12:14 PM Subject: Re: [Opentnl-general] CPU 97% > > --- hongtao <hon...@ho...> wrote: >> i am studying the TNLTest program, when the server >> is runing, even if no client to log in, The CPU will >> be hold by >> the server at 97% to 100%. >> > > Without having disected the program in-depth, I would > assume that it's running in a tight loop at the > moment. As such it'll use whatever CPU is available. > Even if it's using 97% with 0 users, doesn't mean it > would use more than that as you add more clients. > > Having said that, I'm not convinced that OpenTNL is > ideal for MMOGs (if anyone on the list knows > different, please speak up :) ) - it's optimized for > peer-hosted servers (such as Quake, Halflife or > Tribes), rather than centrally hosted ones. Different > paradigms. > > With a peer-hosted service, latency is usually your > key issue. Gaming is often twitch-based (FPS). > > With MMOGs, CPU and bandwidth consumption is much more > important. While many peer-hosted games these days > needs broadband connectivity for 16+ clients, your > average MMOG rarely sends more than 1-2 kb/s to each > client, since it's paying through the nose for each MB > of data transmitted on it's network. Latency is > horrific, but since gameplay by and large isn't > twitch-based, it's not much of a problem. > > Best of luck; > > Allan > > > > Allan Simonsen sim...@ro... > ICQ# 16606984 > > > > > __________________________________ > Celebrate Yahoo!'s 10th Birthday! > Yahoo! Netrospective: 100 Moments of the Web > http://birthday.yahoo.com/netrospective/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general > |
From: Ben G. <bg...@pb...> - 2005-03-07 05:07:51
|
Whoops, sorry. Apparently got my line wrapping turned off. Ben |
From: Ben G. <be...@ga...> - 2005-03-07 05:05:05
|
Allan Simonsen wrote: >Without having disected the program in-depth, I would >assume that it's running in a tight loop at the >moment. As such it'll use whatever CPU is available. >Even if it's using 97% with 0 users, doesn't mean it >would use more than that as you add more clients. > > The TNLTest app is pretty basic, and not at all optimized. It also (unless Mark's rewritten it recently) uses GLUT, which is not very oriented towards minimal CPU usage. >Having said that, I'm not convinced that OpenTNL is >ideal for MMOGs (if anyone on the list knows >different, please speak up :) ) - it's optimized for >peer-hosted servers (such as Quake, Halflife or >Tribes), rather than centrally hosted ones. Different >paradigms. > > The paradigms are the same. Quake, Halflife, and Tribes are all run on central servers. The only difference is that MMOs can swap clients between servers, and tend to be backed by some central databases. Of course, there were some Tribes mods that had database backends, too... :) A peer-hosted game would be something like Age of Empires, which can deal gracefully with the "server" disconnecting - the "server" designation is just for convenience. >With MMOGs, CPU and bandwidth consumption is much more >important. While many peer-hosted games these days >needs broadband connectivity for 16+ clients, your >average MMOG rarely sends more than 1-2 kb/s to each >client, since it's paying through the nose for each MB >of data transmitted on it's network. Latency is >horrific, but since gameplay by and large isn't >twitch-based, it's not much of a problem. > > I'm not really sure which network library you're talking about here. For Zap, a twitch based game which uses TNL, the typical figure is around 2kbps/player. For an MMO type application, you would scale down your update rate and precision - send only one or two updates a second rather than around a dozen. Instead of sending positions as things move, send destinations. And so forth. We did some of those optimizations in Torque for the RTS Starter Kit and were able to get up to around a hundred visible units moving around with very minimal lag. Bandwidth is a crucial issue for _any_ networked simulation, be it MMO, FPS, parallel computing system, etc. and TNL is a very powerful tool for minimizing bandwidth. Ben Garney Torque Technology Director |
From: Allan S. <Sim...@ro...> - 2005-03-07 04:14:27
|
--- hongtao <hon...@ho...> wrote: > i am studying the TNLTest program, when the server > is runing, even if no client to log in, The CPU will > be hold by > the server at 97% to 100%. > Without having disected the program in-depth, I would assume that it's running in a tight loop at the moment. As such it'll use whatever CPU is available. Even if it's using 97% with 0 users, doesn't mean it would use more than that as you add more clients. Having said that, I'm not convinced that OpenTNL is ideal for MMOGs (if anyone on the list knows different, please speak up :) ) - it's optimized for peer-hosted servers (such as Quake, Halflife or Tribes), rather than centrally hosted ones. Different paradigms. With a peer-hosted service, latency is usually your key issue. Gaming is often twitch-based (FPS). With MMOGs, CPU and bandwidth consumption is much more important. While many peer-hosted games these days needs broadband connectivity for 16+ clients, your average MMOG rarely sends more than 1-2 kb/s to each client, since it's paying through the nose for each MB of data transmitted on it's network. Latency is horrific, but since gameplay by and large isn't twitch-based, it's not much of a problem. Best of luck; Allan Allan Simonsen sim...@ro... ICQ# 16606984 __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ |
From: hongtao <hon...@ho...> - 2005-03-06 09:55:23
|
i am studying the TNLTest program, when the server is runing, even if no = client to log in, The CPU will be hold by the server at 97% to 100%. |
From: hongtao <hon...@ho...> - 2005-03-06 00:42:21
|
opentnl is very interesting. i am working on it. if there are 1000 - 10000 players log in one server, who know if opentnl = can=20 work also? who is chinese in this mailing list, i am from china, haha. |
From: hongtao <hon...@ho...> - 2005-03-05 23:58:00
|
i can not post message to this mailing list. |
From: Mark F. <ma...@ga...> - 2005-03-04 23:58:32
|
Just to let people know... if anyone using TNL will be at the Game Developer's Conference next week in San Francisco, feel free to stop by the GarageGames booth (Booth #912) -- we can chat up networking or whatever. - Mark |
From: Mark F. <ma...@ga...> - 2005-03-04 23:57:16
|
What is your project? I'm glad you've found TNL to be useful... - Mark --- "hongtao" <hon...@ho...> wrote: From: "hongtao" <hon...@ho...> Date: Sat, 5 Mar 2005 07:51:42 +0800 To: <ope...@li...> Subject: [Opentnl-general] Hi,every one who is chinese? i am working on opentnl, which is very helpful to my project. |
From: hongtao <hon...@ho...> - 2005-03-04 23:51:52
|
who is chinese?=20 i am working on opentnl, which is very helpful to my project. |
From: hongtao <hon...@ho...> - 2005-03-04 10:20:54
|
who have problems about Opentnl, can contact with me directly.:) |
From: Brad K. <br...@wi...> - 2005-03-01 17:24:23
|
Cool, I thought static_cast would be better, but I wanted to make the error extra noticable if I was making invalid assumptions about some of the non-RPC related code paths calling this code. I'll send along that assignment form shortly. -Brad Mark Frohnmayer wrote: > Hey Brad, > > Thanks for the patch... the contribution form has been updated. I'll integrate this, but I think I'll set it to use static_cast rather than dynamic, since the code calls a function to check the class first which does a dynamic_cast already, and as written it will seg fault on a NULL pointer access anyway if the dynamic_cast fails :) > > - Mark > |
From: Mark F. <ma...@ga...> - 2005-03-01 01:58:30
|
Hey Brad, Thanks for the patch... the contribution form has been updated. I'll integrate this, but I think I'll set it to use static_cast rather than dynamic, since the code calls a function to check the class first which does a dynamic_cast already, and as written it will seg fault on a NULL pointer access anyway if the dynamic_cast fails :) - Mark --- Brad Kittenbrink <br...@wi...> wrote: From: Brad Kittenbrink <br...@wi...> Date: Mon, 28 Feb 2005 17:52:19 -0500 To: ope...@li... Subject: [PATCH] Re: [Opentnl-general] I've been making some updates recently... they will break your code! I'm new to opentnl, so please forgive me if I fail some list etiquette... With regard to the new RPC-related code, the FunctorDecl template classes do not support multiple inheritance, I've attached a patch to add support. However, I'm not sure that this patch doesn't break assumptions made elsewhere. In particular, I switched Functor::dispatch to take an Object* for the argument instead of a void*. This caused no breakage for me, but it seems like it was clearly unintended in the design of the Functor class. Anyways here's my first attempt at a patch. In the absence of the formal contribution form (http://www.opentnl.org/assignment.html), I don't know what to do from here though. -Brad Kittenbrink br...@wi... Mark Frohnmayer wrote: > The CVS repo now has a bunch of RPC-related changes in. The new > RPC/journal/ThreadQueue macros have an extra parameter which is the > argument name list -- so > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 > someArg2), ...) > > becomes > > TNL_IMPLEMENT_RPC(SomeObject, SomeMethod, (S32 someArg1, U32 > someArg2), (someArg1, someArg2), ...) > > The reason for this is that the functions for parsing the RPC arg > lists, marshalling and unmarshalling RPC call data and the assembly > language dispatch functions have all been removed and replaced by a > template based system. The new system is substantially more stable > and extensible to new data types. Visual C++ 6.0 is no longer a TNL > supported compiler. > > I'll be updating the packages as well as the documentation over the > next while... > > - Mark > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |