From msucka0xff at programmer.net Mon Dec 6 16:09:19 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:05 2005 Subject: [Vanilla Devel] glTrek sources? Message-ID: <20041206220919.EF4AE1F50B1@ws1-2.us4.outblaze.com> Hey Nick, I am getting ready to release a new version of the java client based on your updated UI. Was wondering if you would be so kind as to give me the source files in order to shore up any bugs as it gets used, tested, and reports come in from the at large netrek community playerbase. Anyway thanks for the cool client, and hope you're doing well. Cheers, --Bob -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Mon Dec 6 16:26:17 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] Carlos V: pls add glTrekApplet Key Message-ID: <20041206222617.32548101D0@ws1-3.us4.outblaze.com> Carlos, I am preparing to release glTrekApplet, and would like a usable RSA key for servers (INL, public and hockey). Presently it only legitimately runs on continuum because Quozl was kind enough to allow that to help netrek development efforts move forward. However I would like to demo it on a full complement of servers to run it under in order to add more testing hours to the client and an RSA key can help in that regard. Here is the key I would like added to the key chain. Thanks, -bd glTrekApplet-Java-OpenGL-WebClient:ct=glTrekApplet:cr=msucka0xff@programmer.net:\ :cd=Dec 2004:ar=Java1.5-gl4Java2.8.2.0:cl=inl,standard2:\ :cm=glTrekApplet hosted by Debian Linux and broadband cable connection:\ :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Wed Dec 22 17:25:58 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] .players growing, newly created characters not found Message-ID: <20041222232558.GC22897@us.netrek.org> Anyone seen this problem or can think of any causes? Old characters can be used fine. Username and password work, and the stats look fine. New characters can be created; .players grows accordingly. But trying to log in to the new character a second time results in the same behaviour as if the character is not on file. .players grows again. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From carlos at brain.jpl.nasa.gov Wed Dec 22 17:59:19 2004 From: carlos at brain.jpl.nasa.gov (Carlos Y. Villalpando) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] .players growing, newly created characters not found In-Reply-To: <20041222232558.GC22897@us.netrek.org> References: <20041222232558.GC22897@us.netrek.org> Message-ID: <20041222235919.GA21732@brain.jpl.nasa.gov> Quoting James Cameron : > New characters can be created; .players grows accordingly. But trying > to log in to the new character a second time results in the same > behaviour as if the character is not on file. .players grows again. Brainstorming... Hmm, fseek error? Not a system file size thing since the file grows. What's the value of "me->p_pos * sizeof(struct statentry)" Hmm, looking through gdbm called in db.c db_index_fetch() --Carlos V. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From keyos at keyos.org Wed Dec 22 18:15:10 2004 From: keyos at keyos.org (Stas Pirogov) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] .players growing, newly created characters not found In-Reply-To: <20041222232558.GC22897@us.netrek.org> References: <20041222232558.GC22897@us.netrek.org> Message-ID: First thing that I can think of after looking at the code is data corruption at some point in the file. When you use findplayer() it tries to fetch index (in case you use PLAYER_INDEX) or sequentially fetch records of sizeof(struct statentry). In both cases if the file has at some point one wrong record (different size) all following records will become junk (because of wrong record offset). So technically when you have such corruption you will always fail to find player's record in the .players (no matter whether you do or do not use gdbm). On the other side when you fail to add player you just seek to the end of the file and add new record. Easiest way to find out is to read all .players in loop and print player name. At some point you should start getting junk. Trim to the last normal record and it should be ok. Don't really know if it will be practical to use solution I gave (in case this is the problem), but you get the idea. Even if it isn't the case it would be better (IMO) to get rid of direct access to file and just use some kind of hash database instead (same dbm as used for indexes ?). Hopefully it helps. Stas. On Thu, 23 Dec 2004, James Cameron wrote: > Date: Thu, 23 Dec 2004 10:25:58 +1100 > From: James Cameron > Reply-To: Vanilla Netrek Development Mailing List > > To: vanilla-devel@us.netrek.org > Subject: [Vanilla Devel] .players growing, newly created characters not found > > Anyone seen this problem or can think of any causes? > > Old characters can be used fine. Username and password work, and the > stats look fine. > > New characters can be created; .players grows accordingly. But trying > to log in to the new character a second time results in the same > behaviour as if the character is not on file. .players grows again. > > -- > James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Thu Dec 23 04:38:50 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] .players growing, newly created characters not found In-Reply-To: References: <20041222232558.GC22897@us.netrek.org> Message-ID: <20041223103850.GD22897@us.netrek.org> Thanks Carlos and Stas for your thoughts. Indeed, the code in newplayer() simply seeks to the end of file (SEEK_END), and so if anything ever adds something that is not sizeof(struct statentry) then new entries will be added with wrong alignment, and are thus not findable. I agree, I'll need to find the point of departure in the .players file and truncate it at that point. I'm also considering this change for the future; it detects an end of file offset that isn't a multiple of struct statentry, and blindly truncates downwards. int newplayer(struct statentry *player) { int fd, offset, position; ERROR(8,("db.c: newplayer: adding '%s'\n", player->name)); fd = open(PlayerFile, O_RDWR|O_CREAT, 0644); if (fd < 0) return -1; if ((offset = lseek(fd, 0, SEEK_END)) < 0) return -1; position = offset / sizeof(struct statentry); if ((offset % sizeof(struct statentry)) != 0) { ERROR(1,("db.c: newplayer: SEEK_END not multiple of struct statentry, truncating down\n")); offset = position * sizeof(struct statentry); if ((offset = lseek(fd, position, SEEK_SET)) < 0) return -1; } write(fd, (char *) player, sizeof(struct statentry)); close(fd); ERROR(8,("db.c: newplayer: sizeof '%d' offset '%d' position '%d'\n", sizeof(struct statentry), offset, position)); return position; } On Thu, Dec 23, 2004 at 02:15:10AM +0200, Stas Pirogov wrote: > Even if it isn't the case it would be better (IMO) to get rid > of direct access to file and just use some kind of hash database > instead (same dbm as used for indexes ?). Yes, I've thought about that, but the problem is that writes to the file can be done by either the daemon (on ghostbust) or ntserv (on death). Whatever method is chosen might need some way to prevent accidental simultaneous access; currently the lseek() and write() handles that reasonably well; last writer wins. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Mon Dec 27 11:42:12 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] glTrekApplet Testers/Developers Needed Message-ID: <20041227174212.3E3341F50B1@ws1-2.us4.outblaze.com> Folks, glTrekApplet is a web based netrek client written in Java that runs as an applet. It uses the Java 1.5 browser plugin from Sun Microsystems, and the OpenGL libraries from Jausoft GL4Java (OpenGLTM for JavaTM, Version 2.8.2.0). glTrekApplet is based on the java client released originally by Nick Slager, called glTrek. It was modified and extended to run as an applet and connect to netrek servers using Java RMI packages. The RMI component was originally set up to work with JTrekApplet, and was a project that I started and later named obstrek as in observer netrek. I added obstrek to glTrek, and called it glTrekApplet and it is central purpose is web based netrek observation, and a staging point to jump to 3D Netrek versions (http://spacetrek.sourceforge.net/). It works somewhat, but is still buggy and needs testers to identify the bugs, and ppl looking at the code to fix it (which is not necessarily difficult). The most notable bug is difficulty in locking on to players or planets using the galatic (its a bug that needs fixing). The left hand corner of the galactic seems to be OK, but trying to lock to other areas is no good. UDP is also broken, don't try and open it unless you want the client to crash immediately and hose slots. You can try it out at this stage, but you will need to set up your environment. First you need the Java 1.5 Sun Microsystems browser plugin. Second you will need to install gl4Java libraries. Test your setup at this poing with the gl4Java demos. Next open your firewall setting to allow host c-24-4-247-176.client.comcast.net to connect (usually port 1098/1099). Also the client features improved sound effects. Java Plugin: http://java.sun.com Install gl4Java: http://www.jausoft.com/gl4java.html Adjust Firewall Settings: c-24-4-247-176.client.comcast.net ports 1098/1099 The Demo Is At: http://c-24-4-247-176.client.comcast.net/netrek/glTrek.html The Source is At: http://c-24-4-247-176.client.comcast.net/netrek/glTrek-src.jar I will be moving the sources to the Basic's arch repo so we can incorporate your work very soon. For support, comments, contributions goto irc.freenode.net, channel #netrek. For e-mail support copy the contents of the error messages et al from the Java Console and send to msucka0...@programmer.net, Subject glTrekApplet. You may also post to r.g.n. Special Thanks: * Nick Slager, Robert Temple, Ted Tonchev, Quozl, zu22, Basic, Psychosis, Jerub, unbelievr, Steve Sheldon, and many others. -bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Mon Dec 27 20:44:03 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] glTrekApplet Testers/Developers Needed In-Reply-To: <20041227174212.3E3341F50B1@ws1-2.us4.outblaze.com> References: <20041227174212.3E3341F50B1@ws1-2.us4.outblaze.com> Message-ID: <20041228024403.GA2301@us.netrek.org> On Mon, Dec 27, 2004 at 09:42:12AM -0800, . . wrote: > UDP is also broken, don't try and open it unless you > want the client to crash immediately and hose slots. There should be no way for a client to hose slots. If you've found one, then it is a defect, so please work with the server source to fix it. If you don't fix it, then someone wanting to DoS a server need only read your code to figure out a trigger mechanism. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From smckisson at austin.rr.com Tue Dec 28 02:15:57 2004 From: smckisson at austin.rr.com (Shawn McKisson) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] glTrekApplet Testers/Developers Needed In-Reply-To: <20041228024403.GA2301@us.netrek.org> Message-ID: <200412280816.iBS8FxYm015027@ms-smtp-01-eri0.texas.rr.com> I can not reproduce this behavior. Please provide steps to reproduce and I will look into it. -shawn -----Original Message----- From: vanilla-devel-bounces@us.netrek.org [mailto:vanilla-devel-bounces@us.netrek.org] On Behalf Of James Cameron Sent: Monday, December 27, 2004 8:44 PM To: Vanilla Netrek Development Mailing List Subject: Re: [Vanilla Devel] glTrekApplet Testers/Developers Needed On Mon, Dec 27, 2004 at 09:42:12AM -0800, . . wrote: > UDP is also broken, don't try and open it unless you > want the client to crash immediately and hose slots. There should be no way for a client to hose slots. If you've found one, then it is a defect, so please work with the server source to fix it. If you don't fix it, then someone wanting to DoS a server need only read your code to figure out a trigger mechanism. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Tue Dec 28 12:05:22 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] glTrekApplet Testers/Developers Needed Message-ID: <20041228180522.E01254BE65@ws1-1.us4.outblaze.com> James, I'll look carefully at that code and test various conditions on my test bench server to make sure this is not happening. -bd ----- Original Message ----- From: "James Cameron" To: "Vanilla Netrek Development Mailing List" Subject: Re: [Vanilla Devel] glTrekApplet Testers/Developers Needed Date: Tue, 28 Dec 2004 13:44:03 +1100 > > On Mon, Dec 27, 2004 at 09:42:12AM -0800, . . wrote: > > UDP is also broken, don't try and open it unless you > > want the client to crash immediately and hose slots. > > There should be no way for a client to hose slots. If you've found one, > then it is a defect, so please work with the server source to fix it. > > If you don't fix it, then someone wanting to DoS a server need only read > your code to figure out a trigger mechanism. > -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Tue Dec 28 12:08:48 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] glTrekApplet Testers/Developers Needed Message-ID: <20041228180848.BCEAA4BDAB@ws1-1.us4.outblaze.com> Shawn is correct. Also I need to study it too as soon as I can thanks -bd ----- Original Message ----- From: "Shawn McKisson" To: "'Vanilla Netrek Development Mailing List'" Subject: RE: [Vanilla Devel] glTrekApplet Testers/Developers Needed Date: Tue, 28 Dec 2004 02:15:57 -0600 > > I can not reproduce this behavior. > Please provide steps to reproduce and I will look into it. > > -shawn > > -----Original Message----- > From: vanilla-devel-bounces@us.netrek.org > [mailto:vanilla-devel-bounces@us.netrek.org] On Behalf Of James Cameron > Sent: Monday, December 27, 2004 8:44 PM > To: Vanilla Netrek Development Mailing List > Subject: Re: [Vanilla Devel] glTrekApplet Testers/Developers Needed > > On Mon, Dec 27, 2004 at 09:42:12AM -0800, . . wrote: > > UDP is also broken, don't try and open it unless you > > want the client to crash immediately and hose slots. > > There should be no way for a client to hose slots. If you've found one, > then it is a defect, so please work with the server source to fix it. > > If you don't fix it, then someone wanting to DoS a server need only read > your code to figure out a trigger mechanism. > > -- > James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From msucka0xff at programmer.net Thu Dec 30 11:48:47 2004 From: msucka0xff at programmer.net (. .) Date: Wed Jan 12 00:51:06 2005 Subject: [Vanilla Devel] RSA Key Requirements: RFC Message-ID: <20041230174848.1D13D1CE302@ws1-6.us4.outblaze.com> Carlos, Can you please state clearly for the record what the minimum security requirements are for being granted an RSA key that is added to the verification key chain. This may have been written somewhere, but I am not aware of it. A statement to this effect will help people interested in developing clients in Java, Javascript, Gtk-Tkl, Python, PHP, macromedia etc think about a design that will enable them to get their work into the verification keychain. >From my point of view the requirements have not been clearly stated during the past two years of the Java Key fiasco. This has made the job arbitrarily difficult since no one really knows what the Java developers are really trying to create goal wise with a verification design scheme. I don't think this is an unreasonable request-- that the requirements are stated, or you show use where we can see where the minimum requirements have been written. I would like to start a dialog so that we can unequivocate the issue. Also it turns out that Java is a rich enough environment that I am confident that a proposal can be written and reviewed by the developer community that meets these requirements. Thanks, -bd -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Thu Dec 23 04:40:55 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:55 2005 Subject: [Vanilla List] Pregame idle orbit patches? Message-ID: <20041223104055.GE22897@us.netrek.org> Two people have written to me asking for Continuum to inherit also the safe idle in orbit mode used by Pickled. Is this modification publically available anywhere? Or is it, erm, a differentiation that isn't planned to be published? ;-) -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list