opentnl-general Mailing List for Torque Network Library (Page 9)
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: Brad K. <br...@wi...> - 2005-02-28 23:00:32
|
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 > > |
From: Mark F. <ma...@ga...> - 2005-02-22 09:55:20
|
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 |
From: Kevin D. <Kevin@TotallyGames.com> - 2005-02-16 01:05:46
|
Sorry for the delayed response here...Mark answered my question, but Ben, since you asked: The reason it came up and the reason I was hoping to do it as a NetEvent is that we have a case here where clients connect to a server, a whole bunch of setup and interaction happens, and somewhere down the line a game starts. And when the game starts, I'd like it to start as quickly as possible on all the clients. Currently, that Game Start event is being sent as a Guaranteed (not ordered) packet, so it'll get there as quickly as any guaranteed packet can...But if the first packet with the event is lost, it may be a while before the clients finally get it. If it's sent with every packet, then the clients will get it as soon as they receive any packet from the server. I'm looking into the way Zap is doing Quickest Delivery for movement, and I'll likely just follow that model. Thanks again. Ben Garney <be...@ga...> said: > Naturally, you could extend the NetEvent semantics to include a > QuickestDelivery type if you wanted, but I can't think of many good > reasons off the top of my head. Not to say I'm not curious to hear one! :) |
From: Ben G. <be...@ga...> - 2005-02-09 23:03:13
|
Hey Kevin, Mark is likely to be able to give a fuller answer, but here's my understanding - the quickest delivery is for stuff like movement data or current position, not for NetEvents, which are more discrete chunks of information. So if you look at the zap demo app, you'll see that quickest delivery is implemented for the control object (for instance) by simply writing the data out for each packet, using a subclass of GhostConnection. Quickest delivery isn't very useful for NetEvents because in theory they store their data as part of each NetEvent instance, ie, it's not dynamic data. Naturally, you could extend the NetEvent semantics to include a QuickestDelivery type if you wanted, but I can't think of many good reasons off the top of my head. Not to say I'm not curious to hear one! :) Hope this helps. Regards, Ben Garney Torque Technology Director Kevin Deus wrote: > The "Fundamentals" page of the TNL documentation mentions "Quickest >Delivery data" as a strategy for dealing with packet loss. From working >with the library, I can see that the groundblocks are in place for sending >this kind of data, but is there a full implementation of it anywhere, like >there is for Current State data, Guaranteed Ordered data, and so on? > > Ideally, I'm hoping for something like another enum value for >NetEvent::GuaranteeType: something like QuickestDelivery. ...but maybe I'm >looking in the wrong place. > > > >------------------------------------------------------- >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: Mark F. <ma...@ga...> - 2005-02-09 23:02:34
|
We didn't implement a NetEvent type for quickest delivery data -- rather we used that descriptor for data like player Move commands (see the Zap game for an example), where we send unacknowledged Move structures with every packet until one of the packets containing the move is acknowledged. - Mark --- "Kevin Deus" <Kevin@TotallyGames.com> wrote: From: "Kevin Deus" <Kevin@TotallyGames.com> Date: Wed, 9 Feb 2005 11:38:53 -0800 To: <ope...@li...> Subject: [Opentnl-general] Quickest Delivery Data The "Fundamentals" page of the TNL documentation mentions "Quickest Delivery data" as a strategy for dealing with packet loss. From working with the library, I can see that the groundblocks are in place for sending this kind of data, but is there a full implementation of it anywhere, like there is for Current State data, Guaranteed Ordered data, and so on? Ideally, I'm hoping for something like another enum value for NetEvent::GuaranteeType: something like QuickestDelivery. ...but maybe I'm looking in the wrong place. ------------------------------------------------------- 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: Kevin D. <Kevin@TotallyGames.com> - 2005-02-09 19:28:34
|
The "Fundamentals" page of the TNL documentation mentions "Quickest Delivery data" as a strategy for dealing with packet loss. From working with the library, I can see that the groundblocks are in place for sending this kind of data, but is there a full implementation of it anywhere, like there is for Current State data, Guaranteed Ordered data, and so on? Ideally, I'm hoping for something like another enum value for NetEvent::GuaranteeType: something like QuickestDelivery. ...but maybe I'm looking in the wrong place. |
From: Ben G. <bg...@pb...> - 2005-02-05 22:05:34
|
chinmay wrote: > hi all > i have to use rpc with multicasting. means i have to invoke funcitons > on a group of machines, my sending only one message.i have no central > server.all are peer to peer. > > correct me if i am wrong > 1. when we bind address > Address bindAddress(IPProtocol, Address::Any,0) > do i need to make any change here, because after it netInterface > create a new Interface bounded by this address. > please reply as soon as possible > thanks > regards > chinmay > Mark will correct me if I'm wrong, but TNL doesn't support multicast protocols out of the box; it's much more focused on connection-oriented behavior. It would probably be possible to adapt some of the "internal" code (ie, the basic RPC serialization code, the encryption code, etc.) to work in a multicast situation but in general you'd end up tossing a big chunk of TNL out the window to do it. It's something I'd suggest not doing unless you have fairly deep knowledge about multicast... Anyway, TNL connections are pretty lightweight - have you considered just having an NxN network topology and sending the data out that way? Obviously, you'll burn N packets instead of one, but it'd be quick and easy to get running... Regards, Ben Garney Assistant TNL Developer |
From: chinmay <chi...@ii...> - 2005-02-05 17:50:01
|
hi all i have to use rpc with multicasting. means i have to invoke funcitons on a group of machines, my sending only one message.i have no central server.all are peer to peer. correct me if i am wrong 1. when we bind address Address bindAddress(IPProtocol, Address::Any,0) do i need to make any change here, because after it netInterface create a new Interface bounded by this address. please reply as soon as possible thanks regards chinmay |
From: Ben G. <be...@ga...> - 2005-01-23 21:46:20
|
Dan, Unfortunately, it is more probably the case that your video card doesn't support hardware TnL (texture and lighting), rather than that the Torque Networking Library is missing (especially as it's compiled into the programs that use it). The studio that makes SW: Battlefront doesn't have a TNL license, so it's safe to say that they aren't using this particular technology in their product. Sorry that we can't help you more. There's nothing more frustrating than getting a new toy/game for Christmas and not having it work! The Lucas Arts support page can be found here: http://support.lucasarts.com/ Best of luck getting things working, Ben Garney Torque Technology Director dd...@op... wrote: > My daughter received an game (PC) for Christmas. Star Wars - Battlefront. > > We are unable to install it as we get an error message relative to > missing or not found TnL. If we choose to continue it goes through the > installation steps fine. When we try to start the game another error > message pops up regarding C++ and a "Buffer Overrun". > > Might you have any suggestions for us? > > Thanks. > > Dan Dutton > > ------------------------------------------------------- This SF.Net > email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for > open source databases. Create drag-&-drop reports. Save time by over > 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ Opentnl-general > mailing list Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general |
From: <dd...@op...> - 2005-01-23 15:27:23
|
<BODY><P>My daughter received an game (PC) for Christmas. Star Wars - Battlefront.</P> <P>We are unable to install it as we get an error message relative to missing or not found TnL. If we choose to continue it goes through the installation steps fine. When we try to start the game another error message pops up regarding C++ and a "Buffer Overrun". </P> <P>Might you have any suggestions for us?</P> <P>Thanks.</P> <P>Dan Dutton</P></BODY> |
From: Tess S. <ma...@gm...> - 2004-12-16 23:27:39
|
Does anyone know if there's any plan for TNL to support wide character strings (for localization) in the future? Is there already support, but I just didn't notice it? If I need to use wide character strings, do folks recommend: A.) Modifying the current string-related classes and methods to handle it, B.) Just passing it as raw byte data, C.) Adding new classes and methods which mirror the behavior of the standard string classes, or D.) None of the above? Tess |
From: Ben G. <be...@ga...> - 2004-12-14 04:21:45
|
Tess, In fact, we had this situation in Zap for the commander map. :) Basically what we do is when we're in commander map (if I remember correctly), we route control to a scoping method on the GameType, which iterates over the team-members and scopes things near them. Mark can speak to the details; but the code in the SF CVS should help you out in a more direct way. ;) Regards, Ben Garney Tess Snider wrote: >Have any of you attempted to use TNL in an environment with multiple >objects that need to be queried for scoping purposes? For example, if >you were making a top-down RTS, and any one of your units could >potentially uncover an enemy unit, how do you manage the scoping, in >that case? Do you make some kind of umbrella object, which does the >visibility checking for your whole army? Is there some other way to >handle this? > >Thanks! > >Tess > > >------------------------------------------------------- >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://productguide.itmanagersjournal.com/ >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > > > |
From: Mark F. <ma...@ga...> - 2004-12-14 04:06:19
|
I would do just what you suggest -- have an umbrella object that scopes for your entire army. In Zap, the GameType object acts as the scoping object for all clients, and depending on the view of the player either scopes all the objects his team can see (in the command map) or all the objects he can see. - Mark Tess Snider wrote: >Have any of you attempted to use TNL in an environment with multiple >objects that need to be queried for scoping purposes? For example, if >you were making a top-down RTS, and any one of your units could >potentially uncover an enemy unit, how do you manage the scoping, in >that case? Do you make some kind of umbrella object, which does the >visibility checking for your whole army? Is there some other way to >handle this? > >Thanks! > >Tess > > >------------------------------------------------------- >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://productguide.itmanagersjournal.com/ >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Tess S. <ma...@gm...> - 2004-12-14 04:01:01
|
Have any of you attempted to use TNL in an environment with multiple objects that need to be queried for scoping purposes? For example, if you were making a top-down RTS, and any one of your units could potentially uncover an enemy unit, how do you manage the scoping, in that case? Do you make some kind of umbrella object, which does the visibility checking for your whole army? Is there some other way to handle this? Thanks! Tess |
From: Mark F. <ma...@ga...> - 2004-12-08 23:03:50
|
This should work just fine. Let me know if you run into any problems getting it to work. - Mark Kevin Deus wrote: >I was wondering if ghosted objects can themselves be ghosted to other >connections? Here's what I'm trying to do: > >Computer B is connected to computers A and C. > > (A) -- (B) -- (C) > >(A), (B), and (C) all have objects that need to be ghosted to all of the >other machines. If a ghost object from (A) is created on (B), then can (B) >set that object ghostable and get it to ghost to (C)? > >>From looking over the code briefly, I can't see any reason this couldn't >work, but I wanted to check before I start investigating further. > > > >------------------------------------------------------- >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://productguide.itmanagersjournal.com/ >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Kevin D. <Kevin@TotallyGames.com> - 2004-12-08 22:58:03
|
I was wondering if ghosted objects can themselves be ghosted to other connections? Here's what I'm trying to do: Computer B is connected to computers A and C. (A) -- (B) -- (C) (A), (B), and (C) all have objects that need to be ghosted to all of the other machines. If a ghost object from (A) is created on (B), then can (B) set that object ghostable and get it to ghost to (C)? >From looking over the code briefly, I can't see any reason this couldn't work, but I wanted to check before I start investigating further. |
From: John W. <ca...@mm...> - 2004-10-27 14:23:50
|
Boris Koenig wrote: > Mark Frohnmayer wrote: > > >> >> >> It should compile fine with GCC 2.9.5 and 3.x > > > I haven't had problems with that personally, but I think John > can comment on that ? > I've had no problems with GCC 2.9.5 and 3.0. Believe Jon Stockill was having run time problems with the dynamic casting when we ran the field test. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ----- Original Message ----- > From: "Jon Stockill" <li...@st...> > To: "FlightGear developers discussions" <fli...@fl...> > Sent: Saturday, October 09, 2004 3:41 AM > Subject: Re: [Flightgear-devel] Buildiing/running the ATC network test > > >> > >> > And the master falls over: >> > >> > Program received signal SIGSEGV, Segmentation fault. >> > [Switching to Thread 16384 (LWP 11705)] >> > 0x080a3e68 in ?? () >> > (gdb) bt >> > #0 0x080a3e68 in ?? () >> > #1 0x400e0974 in __dynamic_cast (from=0x80a3e68, >> > to=0x807b740 <typeinfo for TNL::Object>, require_public=134723644, >> > address=0x0, sub=0xbfffefb8, subptr=0x4000a490) >> > at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 >> > #2 0x08056613 in TNL::NetConnectionRep::create ( >> > name=0xbfffeb80 "MasterServerConnection") at netConnection.cpp:50 >> > #3 0x0805c458 in TNL::NetInterface::handleConnectRequest (this=0x809a520, > > >>> > address=@0xbffff010, stream=0xbffff030) at netInterface.cpp:762 >>> > #4 0x0805b11f in TNL::NetInterface::processPacket (this=0x809a520, >>> > sourceAddress=@0xbffff010, pStream=0xbffff030) at >> >> >> netInterface.cpp:462 > > >>> > #5 0x0805affb in TNL::NetInterface::checkIncomingPackets(this=0x809a520) >> >> >>> > at netInterface.cpp:422 >>> > #6 0x08049cc6 in main (argc=1, argv=0xbffff7f4) at main.cpp:667 >>> > (gdb) >>> > >>> > >> >> >> It looks like they assert the case when the the NULL pointer is returned, >> but don't catch the exception throw. I guess the bigger question is why the > > >> dynamic_cast fails. Need to dig a little more... >> >> BTW, is this the same problem you had when you tried to connect with the >> controller/pilot nodes during the field test. The test log shows the initial > >> handshake sequence, a couple of resends by the master, and then "silence" > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have been unable to duplicate or decipher where the problem might be. Need to query Jon on more details on system specifics, Linux version, GCC, etc Regards John W. |
From: Boris K. <Fli...@in...> - 2004-10-27 06:26:08
|
Mark Frohnmayer wrote: > Boris Koenig wrote: > >> Mark Frohnmayer wrote: >> >> okay, I see - does that mean, that we might have better chances if we >> simply decided not to use TNL's RPC functionality ? >> > Much of TNL's higher level functionality (GhostConnetion) depends on the > RPC stuff working, so although you could strip it out, you would lose > much useful functionality. This may or may not be an issue depending on > your application. I was merely trying to get some feedback whether not to use RPC functionality would solve some of the porting issues. As John said already: being able to use RPC would definitely be "nice". >> Also, the TNL webpage reads that there's currently only support >> for x86 linux ? > > > For linux, yes. It should also be a trivial port to PPC linux, since > there's a PPC version of the assembly code for OS X. I seel, well I don't think it's necessary to do that - because if the general plans are to slowly migrate over to a template based approach for the platform specific code, it should not be that important for us - regardless of how long the actual migration is going to take. >> A maximally platform-independent implementation would be preferable >> because we could use the TNL for all components of our project, >> while we would otherwise be forced to use the TNL stuff only for the >> client side because most usual server platforms aren't yet supported. > > > Of course... though x86 linux is a fairly common server platform. yes, certainly right - but there's so much POSIX stuff that people use ... x86 is probably not always the first choice. >> Depending on the amount of time that might take, we could meanwhile >> try to determine where exactly the TNL sources need to be modified in >> order to compile with recent versions of GCC - if that'd help. > > > It should compile fine with GCC 2.9.5 and 3.x I haven't had problems with that personally, but I think John can comment on that ? >> Additionally, I would have personally found it helpful if the library >> had been packaged like a standard GNU tarball, including a conventional >> configure/makefile build chain, possibly with a central default location >> where to place the header files - what do you think ? > > > We currently don't have a Unix master on the project to manage such a > thing. Are you volunteering? lol, well I wouldn't mind to look into it in more detail, I just noticed that the current Makefiles mention that you ultimatley intend to switch to autconf/automake, so a first stab at it would probably not be a bad idea, one could still keep the old makefiles around as a fallback solution. ---------- Boris |
From: John W. <ca...@mm...> - 2004-10-27 00:33:06
|
Mark Frohnmayer wrote: > Hi Boris, > > The one gotcha for TNL as far as multiplatform capability is that the > RPC mechanism uses specialized assembly language functions to read > stack arguments and then dispatch the function call on the remote > host. I'm currently working on a version of that code that uses > templates instead, that should be totally cross-platform. What > platforms are you looking at porting to? > > You can look at tnlMethodDispatch.cpp/.h for the architecture specific > assembly code. > One of the more attractive aspects (at least in my ideas for the OpenATC protocol) is the use of the RPC mechanisms. For the interested reader, see Chap 18 in Unix Network Programming by Stevens to better understand the problems and pitfalls in implementing RPCs. 100% cross-platform compatibility is a goal, not an absolute. Regards John W. |
From: Mark F. <ma...@ga...> - 2004-10-26 18:26:55
|
Boris Koenig wrote: > Mark Frohnmayer wrote: > > okay, I see - does that mean, that we might have better chances if we > simply decided not to use TNL's RPC functionality ? > Much of TNL's higher level functionality (GhostConnetion) depends on the RPC stuff working, so although you could strip it out, you would lose much useful functionality. This may or may not be an issue depending on your application. >> I'm currently working on a version of that code that uses templates >> instead, that should be totally ross-platform. > > > sounds good ! :-) > >> What platforms are you looking at porting to? > > > actually, we didn't yet really look into specific platforms, rather we > did "by accident" notice that TNL doesn't seem to compile on each > platform that easily. It should compile directly on x86linux, win32 and Mac OSX. > > That's also when we checked the exact description on the webpage and > noticed the remark that it would generally only compile on three > different platforms, that's where we stopped to look into the details. > > The platforms where we encountered said problems were mostly typical > unix platforms (SGI/Irix) if I remember correctly. > > Also, the TNL webpage reads that there's currently only support > for x86 linux ? For linux, yes. It should also be a trivial port to PPC linux, since there's a PPC version of the assembly code for OS X. > > A maximally platform-independent implementation would be preferable > because we could use the TNL for all components of our project, > while we would otherwise be forced to use the TNL stuff only for the > client side because most usual server platforms aren't yet supported. Of course... though x86 linux is a fairly common server platform. > Depending on the amount of time that might take, we could meanwhile > try to determine where exactly the TNL sources need to be modified in > order to compile with recent versions of GCC - if that'd help. It should compile fine with GCC 2.9.5 and 3.x > > Additionally, I would have personally found it helpful if the library > had been packaged like a standard GNU tarball, including a conventional > configure/makefile build chain, possibly with a central default location > where to place the header files - what do you think ? We currently don't have a Unix master on the project to manage such a thing. Are you volunteering? :) - Mark |
From: Boris K. <Fli...@in...> - 2004-10-26 18:13:06
|
Mark Frohnmayer wrote: > Hi Boris, Hi Mark ! > The one gotcha for TNL as far as multiplatform capability is that the > RPC mechanism uses specialized assembly language functions to read stack > arguments and then dispatch the function call on the remote host. okay, I see - does that mean, that we might have better chances if we simply decided not to use TNL's RPC functionality ? > I'm currently working on a version of that code that uses templates instead, > that should be totally ross-platform. sounds good ! :-) > What platforms are you looking at porting to? actually, we didn't yet really look into specific platforms, rather we did "by accident" notice that TNL doesn't seem to compile on each platform that easily. That's also when we checked the exact description on the webpage and noticed the remark that it would generally only compile on three different platforms, that's where we stopped to look into the details. The platforms where we encountered said problems were mostly typical unix platforms (SGI/Irix) if I remember correctly. Also, the TNL webpage reads that there's currently only support for x86 linux ? A maximally platform-independent implementation would be preferable because we could use the TNL for all components of our project, while we would otherwise be forced to use the TNL stuff only for the client side because most usual server platforms aren't yet supported. I am sure that other users of your library would probably also benefit from such an almost "platform-independent" implementation. > You can look at tnlMethodDispatch.cpp/.h for the architecture specific > assembly code. Okay, thanks for that hint - I am going to look into it, but actually we wouldn't want to mess around with assembly code. How much work do you think is involved in porting the current assembly code-based approach over to a pure C++/template oriented one ? Depending on the amount of time that might take, we could meanwhile try to determine where exactly the TNL sources need to be modified in order to compile with recent versions of GCC - if that'd help. Additionally, I would have personally found it helpful if the library had been packaged like a standard GNU tarball, including a conventional configure/makefile build chain, possibly with a central default location where to place the header files - what do you think ? Thanks -------- Boris |
From: Mark F. <ma...@ga...> - 2004-10-26 17:38:01
|
Hi Boris, The one gotcha for TNL as far as multiplatform capability is that the RPC mechanism uses specialized assembly language functions to read stack arguments and then dispatch the function call on the remote host. I'm currently working on a version of that code that uses templates instead, that should be totally cross-platform. What platforms are you looking at porting to? You can look at tnlMethodDispatch.cpp/.h for the architecture specific assembly code. - Mark Boris Koenig wrote: > Hi ! > > We would like to use the TNL for a project where a high level of > cross-platform compatability is very much desired. > > Having been recommended to use the TNL, we considered it a very > interesting project and a good choice. > > However, a couple of weeks ago we learnt that the TNL currently > compiles only on a relatively small set of platforms - compared to > other cross-platform networking libraries that compile on > pretty much any POSIX-compliant OS, - also there seem to be > problems related to using recent GCC versions ? > > Regardless of that, we'd still like to use the TNL for our project, > simply because it seems by far the most powerful and user-friendly > library that's available - and libraries like ACE would certainly > be beyond the scope of our project. > > So, we're hoping to be able to obtain our goals relatively quickly > using the TNL. > > We are wondering what would be involved in trying to port the TNL > to another platforms, whether there have been any such efforts attempted > before and what hurdles we can expect to face. > > We did read on your webpage that the TNL should actually be fairly > "simple" to port over to other platforms, as it uses platform specific > "modules", having recently looked into the platforms.h and tnlTypes.h > headers, it seems somewhat possible to give it a go, however we'd > still like to get some feedback about the process itself and the things > that we need to keep an eye on - possibly there are even some pointers > about the porting process ? > > Maybe you folks can at least provide us with some feedback about > how feasible the attempt would really be - or simply why exactly > it is that the TNL currently compiles only on a relatively small > set of platforms, taking into account that it is supposed to be > "cross-platform". > > > Thanks for your help in advance > > > ---------- > Boris > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general |
From: Boris K. <Fli...@in...> - 2004-10-26 15:33:18
|
Hi ! We would like to use the TNL for a project where a high level of cross-platform compatability is very much desired. Having been recommended to use the TNL, we considered it a very interesting project and a good choice. However, a couple of weeks ago we learnt that the TNL currently compiles only on a relatively small set of platforms - compared to other cross-platform networking libraries that compile on pretty much any POSIX-compliant OS, - also there seem to be problems related to using recent GCC versions ? Regardless of that, we'd still like to use the TNL for our project, simply because it seems by far the most powerful and user-friendly library that's available - and libraries like ACE would certainly be beyond the scope of our project. So, we're hoping to be able to obtain our goals relatively quickly using the TNL. We are wondering what would be involved in trying to port the TNL to another platforms, whether there have been any such efforts attempted before and what hurdles we can expect to face. We did read on your webpage that the TNL should actually be fairly "simple" to port over to other platforms, as it uses platform specific "modules", having recently looked into the platforms.h and tnlTypes.h headers, it seems somewhat possible to give it a go, however we'd still like to get some feedback about the process itself and the things that we need to keep an eye on - possibly there are even some pointers about the porting process ? Maybe you folks can at least provide us with some feedback about how feasible the attempt would really be - or simply why exactly it is that the TNL currently compiles only on a relatively small set of platforms, taking into account that it is supposed to be "cross-platform". Thanks for your help in advance ---------- Boris |
From: Kevin D. <Kevin@TotallyGames.com> - 2004-10-18 18:33:03
|
I sent a couple of emails about this, one to su...@ga... last Tuesday and one to bus...@ga... on Friday, but the first one I received no response to and the second one failed delivery. If there's a better place for me to send these questions, please let me know. Sending these to a mailing list isn't my ideal choice. We've been looking into using the Torque Network Library for an upcoming project, and there are a few questions we were hoping for clarification on: If we buy a commercial license, can we use the license for as many projects as we want, or do we need to purchase a new license for each project? My impression is that the license is only based on the number of seats, not based on the number of projects. Does the license give us access to any extra support? It doesn't sound like it does. Another company will be taking over this project after we're done. How does this work with the licensing agreement and what sort of complications might it create? When we pass the project off to them, can we pass them the .lib for TNL? Can we pass them the source? If they need to modify the TNL code, would they need to purchase a license? And a clarification, partially related to the previous question: if there's only 1 programmer that ever touches the TNL source, and this is then compiled into a library that everyone else uses, would we only need 1 license? Is this different if other programmers need access to the header files? From the sounds of it, the license specifies the number of machines that TNL can be installed on. If everyone else can use a .lib without needing to install TNL, they shouldn't need a license? What's the future of TNL look like? Do you have a roadmap for features and upgrades you plan to add? Or will TNL remain roughly as-is? And I haven't looked into this in detail yet, but is the encryption supported by TNL exportable outside the US? --------------------------------------------------------- Kevin Deus, Kevin@TotallyGames.com |
From: Mark F. <ma...@ga...> - 2004-08-20 17:57:29
|
Looks like this was the same bug where pings and acks on an encrypted=20 connection were being dropped. It's fixed in the head version. - Mark Herv=E9 Denis wrote: >Hello, > >I have a client which is disconnected after 50 seconds without networkin= g activity (PingRetryCount * PingTimeout). Is this normal? >If I look at the checkTimeout() method the server try to send a ping pac= ket to check if the connection is still alive. >Should the server reveive an ack packet in return? > >I'm wondering if I must send packets every n seconds to avoid deconnecti= on or TNL handles this automatically >(and so there is a problem in my code because it doesn't work and the cl= ient is disconnected). > >Thanks in advance, >Herve > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 >digital self defense, top technical experts, no vendor pitches,=20 >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > =20 > |