From bgrubin at cs.tufts.edu Thu Jun 17 12:17:31 2004 From: bgrubin at cs.tufts.edu (Benjamin P.Grubin) Date: Wed Jan 12 00:50:17 2005 Subject: [Netrek Clients] Mac OS X/Darwin Message-ID: <37894F1A-C082-11D8-ADCF-000A957A14FE@cs.tufts.edu> Hey, The current BRMH binary that is posted on netrek.org for OS X is dynamic. This seems to pose a problem, since the binary does not run on Panther (10.3). So.. (1) Can someone compile a static BRMH or (preferably) COW on Darwin/X? I can volunteer system access with full tool set to accomplish this. or (2) Can I build a Panther COW/BRMH client and have it keyed? Please respond via email since I am not subscribed. Thx. Ben _______________________________________________ vanilla-clients mailing list vanilla-clients@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-clients From vanillatrek at yahoo.com Tue Jun 1 09:54:24 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:01 2005 Subject: [Vanilla Devel] Compilation error. In-Reply-To: <40BC0BE7.6000402@netrek.org> Message-ID: <20040601145424.98436.qmail@web21109.mail.yahoo.com> How does one calculate and check the md5sum? Is there a file in Vanilla that lists the latest sums? How does one know the md5sum hasn't been hacked? Zach --- "E. Hietbrink" wrote: > James Cameron wrote: > > > On Mon, May 31, 2004 at 02:55:00PM +0200, E. Hietbrink > wrote: > > > >>I ran accross the following compilation error. Probably > someone made > >>a typo. The fix is trivial. Plz apply remove the > non-space character. > >>disengage.c: In function `in_home_area': > >>disengage.c:601: parse error at null character > > > > > > Can't find anything there in my copy from CVS. Check > the md5sum. > > > > dc1de46b13a16f0dc891d02a0794c463 disengage.c > > > > Revision 1.2. > > > > Compiles fine. > > Damn. when I retrieved it again from CVS it looked fine. > > MD5 (disengage.c) = dc1de46b13a16f0dc891d02a0794c463 > > Sorry for bothering you. > > Greetx, Erik > > > > > _______________________________________________ > vanilla-devel mailing list > vanilla-devel@us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-devel __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Tue Jun 1 18:59:20 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:01 2005 Subject: [Vanilla Devel] Compilation error. In-Reply-To: <20040601145424.98436.qmail@web21109.mail.yahoo.com> References: <40BC0BE7.6000402@netrek.org> <20040601145424.98436.qmail@web21109.mail.yahoo.com> Message-ID: <20040601235920.GD18359@us.netrek.org> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Tue Jun 1 19:31:24 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:01 2005 Subject: [Vanilla Devel] Compilation error. In-Reply-To: <20040601235920.GD18359@us.netrek.org> Message-ID: <20040602003124.49561.qmail@web21110.mail.yahoo.com> --- James Cameron wrote: > > One reads the man page for the md5sum command. If you > have no system > handy with such a man page, use google on a query "man > page of md5sum". Ah! Ta~ > No. There is no need. When Vanilla is released, an > md5sum of the whole > package .tar.gz is included in the release announcement. Is it possible for a hacker to break into my system, alter the tarball package and yet for the md5sum to remain unaltered? > One doesn't. Use digital signatures. I sign release > announcements. > I'll sign this message. If your e-mail service can't > hack digital > signatures, use a better one. I found this attached: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAvRhYbmRwv64kZsARAkwrAJ9JtYSfmPg1cm46ucQkRkEAvRcgHACfcLkJ 4e+VsYzEaLacUJVqwRwF3E4= =O7rS -----END PGP SIGNATURE----- So now how would I send you a message encrypted with the key? Zach __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From Shadow.Hunter at netrek.org Wed Jun 2 00:45:52 2004 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:51:01 2005 Subject: [Vanilla Devel] Compilation error. In-Reply-To: <20040602003124.49561.qmail@web21110.mail.yahoo.com> References: <20040602003124.49561.qmail@web21110.mail.yahoo.com> Message-ID: <40BD6990.7030705@netrek.org> Hi Zach, >>No. There is no need. When Vanilla is released, an md5sum of the whole >>package .tar.gz is included in the release announcement. > Is it possible for a hacker to break into my system, alter > the tarball package and yet for the md5sum to remain > unaltered? The MD5 sum is a cryptographic hash function. That means it makes some sort of summary over a large amount of data, with the mathematical certainty that there is an X chance that one can find an alternative set of data that yields the same summary. Usually the chances that that alternative set of data makes is a valid and sensible tar file is zero. >>One doesn't. Use digital signatures. I sign release announcements. >>I'll sign this message. If your e-mail service can't hack digital >>signatures, use a better one. > So now how would I send you a message encrypted with the > key? That is not his key, its a signature over the email message. It is calculated using his private key. Your email program will also calculate it, but using his public key for it. If both the calculates signatures are equal then you know that the message is unaltered AND that james is the only one that could have signed it. The only waekness in this story is, how do YOU get the correct public keys from James? How do you make sure they are actually his? Usually people upload them to a PGP key server, like james': http://pgp.mit.edu:11371/pks/lookup?search=quozl%40us.netrek.org&op=index (is the last one really yours James?) and mine: http://pgp.mit.edu:11371/pks/lookup?search=shadow.hunter%40netrek.org&op=index But until you have verified with the person in some way that that public key belongs to him you still cannot fully trust it. Afterall you acquired the key over an insecure medium. For software: play around with GPG (open source PGP, http://www.gnupg.org/) and the secure email extension for Mozilla email: http://enigmail.mozdev.org/ In general: read up on cryptography. The GPG website should give you some pointers. Greetx, Erik _______________________________________________ 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 Jun 2 03:29:05 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:01 2005 Subject: [Vanilla Devel] Compilation error. In-Reply-To: <40BD6990.7030705@netrek.org> References: <20040602003124.49561.qmail@web21110.mail.yahoo.com> <40BD6990.7030705@netrek.org> Message-ID: <20040602082905.GD25275@us.netrek.org> On Wed, Jun 02, 2004 at 07:45:52AM +0200, E. Hietbrink wrote: > Usually the chances that that alternative set of data makes is > a valid and sensible tar file is zero. Emotionally valid but mathematically incorrect. Add the word "near" just before the word "zero". With faster processors and farms of compromised machines to draw from, the effort required to create a valid tar by adding compensating garbage must surely be decreasing. I'd bow to actual mathematical analysis though, and so should you, Zach. > Usually people upload them to a PGP key server, like james': > http://pgp.mit.edu:11371/pks/lookup?search=quozl%40us.netrek.org&op=index > (is the last one really yours James?) All three are mine. Sigh. AE2466C0 is my current for that identity. Good reply, Erik, saved me some typing. ;-) I'll add one more ... with spam rates up so high, one of my next steps is to only accept digitally signed messages. And once they catch on to that, only if the signature is trusted. This means, Zach, that unless you can get into crypto mail, you'll be on the outer, eventually. Web mail and crypto ... forget it. Get a real mail account. ;-} -- 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 ANTIGEN_ATKVHKEPOS at atkv.org.za Wed Jun 2 12:47:29 2004 From: ANTIGEN_ATKVHKEPOS at atkv.org.za (ANTIGEN_ATKVHKEPOS@atkv.org.za) Date: Wed Jan 12 00:51:01 2005 Subject: [Vanilla Devel] Antigen found VIRUS= I-Worm.NetSky.d (Kaspersky, Sophos, NAI, CA(Ino culateIT),CA(Vet),VBuster,Norman) worm Message-ID: Antigen for Exchange found your_picture.pif infected with VIRUS= I-Worm.NetSky.d (Kaspersky,Sophos,NAI,CA(InoculateIT),CA(Vet),VBuster,Norman) worm. The message is currently Purged. The message, "Re: Your picture", was sent from vanilla-devel@us.netrek.org and was discovered in IMC Queues\Inbound located at ATKV/HK/ATKVHKEPOS. _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From Shadow.Hunter at netrek.org Mon Jun 7 13:05:15 2004 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:51:01 2005 Subject: [Vanilla Devel] Metaserver listing for INL servers In-Reply-To: <20040514000729.GA6656@us.netrek.org> References: <40A3D579.7080001@netrek.org> <20040514000729.GA6656@us.netrek.org> Message-ID: <40C4AE5B.9030602@netrek.org> Hi James, As discussed I implemented and tested (server-side only) the addition of the metaserver listing for INL server feature. I followed your suggestion and used this as my .metaservers file: metaserver.us.netrek.org 3521 60 120 home.nl.netrek.org I 4566 4000 open metaserver.us.netrek.org 3521 60 120 away.nl.netrek.org I 4577 5000 open metaserver2.us.netrek.org 3521 60 120 home.nl.netrek.org I 4566 4000 open metaserver2.us.netrek.org 3521 60 120 away.nl.netrek.org I 4577 5000 open The server now gets properly listed on the metaserver: Server Host Port Ago Status Flags --------------------------------------- -------- ---- ----------------- ------- -h away.nl.netrek.org -p 4577 43 Nobody playing I -h home.nl.netrek.org -p 4566 0 OPEN: 1 player I Since I dislike having all INL servers show up on the metaserver list even when there are no players on it (which is 99.9% of the time), I made it so that only when there are actually players on it, the metaserver is informed. When the last player logs out it will send a final players=0 update and that's it. That means that after 60 minutes (this I tested) the entry will be automatically removed from the metaserver. So how does the server get listed in the first place then you may wonder? Well, I hope that the old clue players know how to use -h host -p port command line options. They will probably be the ones to call a clue game, so they will enter first too. And that triggers the metaserver listing. Client changes required! I see NetrekXP already shows entries of type "I" (=INL). Had not expected that. Anyway. the change required is stripping off "home." and "away." from the start of the hostname and only *displaying* that on screen. Should be trivial. I will do that later for NetrekXP. Attached you find 2 files: solicit.c and solicit.h. In the latter I had to increase MAXMETASERVERS to 4, so that my 4 entries would all work (2 metaservers, each has a home/away). There is a small 64bit bugfix in there too. Someone did a nice pointer copy and thought only of 32bit ;-) James: there's still a lot of extraneous fprintf() statements in. If you apply the patch, you can safely remove them.. Greetx, Erik James Cameron wrote: > Erik, > > I've had a look at the metaserver code just now, at scan.c and > disp_udp.c, and it would be quite simple to adjust that to account for > INL servers. I made the UDP protocol extensible. > > But you mentioned port 3521. Does the NetrekXP client use the UDP or > TCP connection? If TCP, then I don't think I'd like to change the > format. I'd really like Stas to use UDP if he can. ;-) > > To hack it now without changing any code, in the backwards compatible > way, the .metaservers file for the INL server should contain one line > for each port, using a DNS alias. > > For example; > > metaserver.us.netrek.org 3521 60 120 pickup.nl.netrek.org B 2592 2593 open > metaserver.us.netrek.org 3521 60 120 home.nl.netrek.org B 4566 4000 open > metaserver.us.netrek.org 3521 60 120 away.nl.netrek.org B 4577 5000 open > metaserver.us.netrek.org 3521 60 120 home-observers.nl.netrek.org B 4000 > ... > > We should add a server type for an INL server, and include INL servers > that have solicited in the response to the client. I'd want to make a > new server side protocol version to include all four ports. I'd expect > the client developers to accept four ports and figure a way to display > it! > > Erik wrote: > >> b) Currently only the player port is listed! > > > Yes, that's insufficient. > > We didn't design in a protocol version number for the client UDP query, > but there's room; only the first character is checked now and it must be > a question mark. We could add a version number after that, and have the > later version cause more ports to be listed. > > I'm happy to change COW. > > >>3) Problem is I have not yet found the point where to put the >> call to solicit(). How can the server check if it is an INL >> server? > > > (status->gameup & GU_INROBOT) > > The flag is set by the INL robot. > > >> Which process owns that metaservers[] table? > > > Daemon. > > >> Should the check be done in deamon (which has the solicit() call), >> or in netrekd when a player enters? > > > Daemon. It won't be running until a player enters. > > >>Any feedback is appreciated. I am really convinced this is a >>necessary feature to promote clue netrek to midbies who simply >>happen to not be a computer wizard ;-) > > > I agree. > -------------- next part -------------- #include #include #include #include #include #include #include #include #include "defs.h" #include "struct.h" #include "data.h" #include "solicit.h" /* our copy of .metaservers file */ static struct metaserver metaservers[MAXMETASERVERS]; /* initialisation done flag */ static int initialised = 0; /* remove non-printable chars in a string. Lifted from tools/players.c */ /* with a minor addition: error checking on the strdup */ static char *name_fix(char *name) { char *new = strdup(name); /* xx, never freed */ register char *r = new; if(!new) return new; /* don't play with null ptr */ while(*name){ *r++ = (*name <= 32)?'_':*name; name++; } *r = 0; return new; } /* attach to a metaserver, i.e. prepare the socket */ static int udp_attach(struct metaserver *m) { char *our_server = m->ours; /* create the socket structure */ m->sock = socket(AF_INET, SOCK_DGRAM, 0); if (m->sock < 0) { perror("solicit: udp_attach: socket"); return 0; } /* bind the local socket */ /* bind to interface attatched to this.host.name */ /* first check if perhaps it is a fake INL server address */ if( ( m->type[0] == 'I' || m->type[0] == 'i' ) && ( strncasecmp( m->ours, "home.", 5 ) == 0 || strncasecmp( m->ours, "away.", 5 ) == 0 ) ) { our_server += 5; } /* numeric first */ if( (m->address.sin_addr.s_addr = inet_addr( our_server )) == -1 ) { struct hostent *hp; /* then name */ if ((hp = gethostbyname( our_server )) == NULL) { /* bad hostname or unable to get ip address */ fprintf(stderr, "Bad this.host.name field in .metaservers.\n"); return 0; } else { // m->address.sin_addr.s_addr = *(long *) hp->h_addr; NOT 64BIT SAFE memcpy( &(m->address.sin_addr.s_addr), hp->h_addr, 4); } } m->address.sin_family = AF_INET; m->address.sin_port = 0; if (bind(m->sock,(struct sockaddr *)&m->address, sizeof(m->address)) < 0) { perror("solicit: udp_attach: unable to bind to desired interface (this.host.name field)"); return 0; } /* build the destination address */ m->address.sin_family = AF_INET; m->address.sin_port = htons(m->port); /* attempt numeric translation first */ if ((m->address.sin_addr.s_addr = inet_addr(m->host)) == -1) { struct hostent *hp; /* then translation by name */ if ((hp = gethostbyname(m->host)) == NULL) { /* if it didn't work, return failure and warning */ fprintf(stderr, "solicit: udp_attach: host %s not known\n", m->host); return 0; } else { // m->address.sin_addr.s_addr = *(long *) hp->h_addr; NOT 64BIT SAFE memcpy( &(m->address.sin_addr.s_addr), hp->h_addr, 4); } } return 1; } /* transmit a packet to the metaserver */ static int udp_tx(struct metaserver *m, char *buffer, int length) { int i; /* send the packet */ fprintf(stderr, "solicit: udp_tx: sendto (size:%d)\n", length ); if (sendto(m->sock, buffer, length, 0, (struct sockaddr *)&m->address, sizeof(m->address)) < 0) { perror("solicit: udp_tx: sendto"); return 0; } return 1; } void solicit(int force) { int i, nplayers=0, nfree=0; char packet[MAXMETABYTES]; /* static char prior[MAXMETABYTES];*/ char *fixed_name, *fixed_login; /* name/login stripped of unprintables */ char *name, *login; /* name and login guaranteed not blank */ char unknown[] = "unknown"; /* unknown player/login string */ char *here = packet; time_t now = time(NULL); int gamefull = 0; /* is the game full? */ int isrsa = 0; /* is this server RSA? */ /* perform first time initialisation */ if (initialised == 0) { FILE *file; /* clear metaserver socket list */ for (i=0; ihost, token, 32); token = strtok(NULL, " "); /* meta port */ if (token == NULL) continue; m->port = atoi(token); token = strtok(NULL, " "); /* min solicit time */ if (token == NULL) continue; m->minimum = atoi(token); token = strtok(NULL, " "); /* max solicit time */ if (token == NULL) continue; m->maximum = atoi(token); token = strtok(NULL, " "); /* our host name */ if (token == NULL) continue; strncpy(m->ours, token, 32); token = strtok(NULL, " "); /* server type */ if (token == NULL) continue; strncpy(m->type, token, 2); token = strtok(NULL, " "); /* player port */ if (token == NULL) continue; m->pport = atoi(token); token = strtok(NULL, " "); /* observer port */ if (token == NULL) continue; m->oport = atoi(token); token = strtok(NULL, "\n"); /* comment text */ if (token == NULL) continue; strncpy(m->comment, token, 32); /* force minimum and maximum delays (see note on #define) */ if (m->minimum < META_MINIMUM_DELAY) m->minimum = META_MINIMUM_DELAY; if (m->maximum > META_MAXIMUM_DELAY) m->maximum = META_MAXIMUM_DELAY; /* attach to the metaserver (DNS lookup is only delay) */ udp_attach(m); /* place metaserver addresses in /etc/hosts to speed this */ /* use numeric metaserver address to speed this */ /* initialise the other parts of the structure */ m->sent = 0; strcpy(m->prior, ""); } initialised++; fclose(file); } printf("solicit call!\n\n" ); /* update each metaserver */ for (i=0; iours, m->type, m->pport, m->oport, m->host, m->port ); /* skip empty metaserver entries */ if (m->sock == -1) { fprintf(stderr, " skip empty metaserver entries\n" ); continue; } /* only process entries with the correct server type */ if( status->gameup & GU_INROBOT && m->type[0] != 'i' && m->type[0] != 'I' ) { fprintf(stderr, " skip metaserver entries with non-INL type during INL mode\n" ); continue; } else if( !(status->gameup & GU_INROBOT) && ( m->type[0] == 'i' || m->type[0] == 'I' ) ) { fprintf(stderr, " skip metaserver entries with INL type during non-INL mode\n" ); continue; } /* if we told metaserver recently, don't speak yet */ if (!force) if ((now-m->sent) < m->minimum) continue; /* don't remake the packet unless necessary */ /* for INL the always recreate because we have multiple ports */ if ( status->gameup & GU_INROBOT ) { here = packet; nplayers=0; nfree=0; gamefull=0; isrsa=0; } if ( here == packet ) { if (status->gameup & GU_NEWBIE) { for (j = 0; j < queues[QU_NEWBIE_PLR].high_slot; j++) { if (players[j].p_status == PFREE) nfree++; else nplayers++; } } else if (status->gameup & GU_PRET) { for (j = 0; j < queues[QU_PRET_PLR].high_slot; j++) { if (players[j].p_status == PFREE) nfree++; else nplayers++; } } else if (status->gameup & GU_INROBOT && strncasecmp( m->ours, "home.", 5 ) == 0 ) { for (j = queues[QU_HOME].low_slot; j < queues[QU_HOME].high_slot; j++) { if (players[j].p_status == PFREE) nfree++; else nplayers++; } } else if (status->gameup & GU_INROBOT && strncasecmp( m->ours, "away.", 5 ) == 0 ) { for (j = queues[QU_AWAY].low_slot; j < queues[QU_AWAY].high_slot; j++) { if (players[j].p_status == PFREE) nfree++; else nplayers++; } } else { for (j = 0; j < queues[QU_PICKUP].high_slot; j++) { if (players[j].p_status == PFREE) nfree++; else nplayers++; } } fprintf(stderr, "before: nfree=%d nplayers=%d gamefull=%d\n", nfree, nplayers, gamefull ); /* Special case: do *not* report anything for INL servers if nplayers=0, except one last time when players are leaving. Actually i just want to delist the server. is there a better way? ehb */ if( nplayers == 0 && status->gameup & GU_INROBOT && ( strcmp(packet, m->prior) == 0 || strcmp( m->prior, "") == 0 ) ) { fprintf(stderr, " skip metaserver entries during INL mode if zero players\n" ); continue; } /* if the free slots are zero, translate it to a queue length */ /* and report that the game is full */ if (nfree == 0) { if (status->gameup & GU_NEWBIE) nfree = -queues[QU_NEWBIE_PLR].count; else if (status->gameup & GU_PRET) nfree = -queues[QU_PRET_PLR].count; else if (status->gameup & GU_INROBOT && strncasecmp( m->ours, "home.", 5 ) == 0 ) nfree = -queues[QU_HOME].count; else if (status->gameup & GU_INROBOT && strncasecmp( m->ours, "away.", 5 ) == 0 ) nfree = -queues[QU_AWAY].count; else nfree = -queues[QU_PICKUP].count; gamefull++; } fprintf(stderr, " nfree=%d nplayers=%d gamefull=%d\n", nfree, nplayers, gamefull ); #ifdef RSA isrsa++; /* this is an RSA server */ #endif /* build start of the packet, the server information */ sprintf(here, "%s\n%s\n%s\n%d\n%d\n%d\n%d\n%s\n%s\n%s\n%s\n", /* version */ "b", /* address */ m->ours, /* type */ m->type, /* port */ m->pport, /* observe */ m->oport, /* players */ nplayers, /* free */ nfree, /* t-mode */ status->tourn ? "y" : "n", /* RSA */ isrsa ? "y" : "n", /* full */ gamefull ? "y" : "n", /* comment */ m->comment ); here += strlen(here); /* now append per-player information to the packet */ for (j=0; jsent) > m->maximum) force=1; /* if we are not forcing an update, and nothing has changed, drop */ if (!force) if (!strcmp(packet, m->prior)) { fprintf( stderr, " No change in packet since last time. dont send.\n" ); continue; } /* send the packet */ if (udp_tx(m, packet, here-packet)) { m->sent=time(NULL); strcpy(m->prior, packet); } } } -------------- next part -------------- /* bytes to reserve for outgoing packet to metaserver */ #define MAXMETABYTES 2048 /* maximum number of metaservers supported */ #define MAXMETASERVERS 4 /* minimum allowable delay between updates to metaserver */ #define META_MINIMUM_DELAY 60 /* Note: changing this may cause the metaserver to delist your server */ /* maximum delay between updates to metaserver */ #define META_MAXIMUM_DELAY 900 /* ship classes (wish these were in data.c/data.h) */ /* static char *ships[] = {"SC", "DD", "CA", "BB", "AS", "SB", "GA"}; */ /* structure of information about a single metaserver */ struct metaserver { /* data items derived from metaservers file */ char host[32]; /* address of metaserver (DNS) */ int port; /* port of metaserver */ int minimum; /* minimum update time */ int maximum; /* maximum update time */ char ours[32]; /* DNS address of server */ char type[2]; /* server type code (B/P/C/H/?) */ int pport; /* server main player port (e.g. 2592) */ int oport; /* server observer player port */ char comment[32]; /* comment string */ /* our own data about the communication with the metaserver */ int sock; /* our socket number */ struct sockaddr_in address; /* address of metaserver */ time_t sent; /* date time metaserver last updated */ char prior[MAXMETABYTES]; /* prior packet sent */ }; void solicit(int force); -------------- next part -------------- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Mon Jun 7 17:57:59 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:02 2005 Subject: [Vanilla Devel] Metaserver listing for INL servers In-Reply-To: <40C4AE5B.9030602@netrek.org> Message-ID: <20040607225759.7297.qmail@web21113.mail.yahoo.com> --- "E. Hietbrink" wrote: > >There is a small 64bit bugfix in there too. Someone did a >nice pointer copy and thought only of 32bit ;-) Hallo Erik, Cool. Good work. Hey how does one determine if their development system supports 32 or 64 bit integers? Won't 64-bit systems still compile the 32-bit code correctly or do you mean that having 64-bit-written code is more efficient? Zach __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From Shadow.Hunter at netrek.org Tue Jun 8 00:15:22 2004 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:51:02 2005 Subject: [Vanilla Devel] Metaserver listing for INL servers In-Reply-To: <20040607225759.7297.qmail@web21113.mail.yahoo.com> References: <20040607225759.7297.qmail@web21113.mail.yahoo.com> Message-ID: <40C54B6A.6010707@netrek.org> Zach wrote: > --- "E. Hietbrink" wrote: > >>There is a small 64bit bugfix in there too. Someone did a >>nice pointer copy and thought only of 32bit ;-) > > > Hallo Erik, > > Cool. Good work. Hey how does one determine if their > development system supports 32 or 64 bit integers? > Won't 64-bit systems still compile the 32-bit code > correctly or do you mean that having 64-bit-written code is > more efficient? > > Zach Nah compare it to russians and italians. Both their languages have the same expression value, only the italians open their mouths twice as wide when they speak. Current 64-bit machine architectures that i know of: AMD64, Itanium, Alpha, Sparc64 (=my machine). Greetx, Erik _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Tue Jun 8 02:29:03 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:02 2005 Subject: [Vanilla Devel] Metaserver listing for INL servers In-Reply-To: <40C4AE5B.9030602@netrek.org> References: <40A3D579.7080001@netrek.org> <20040514000729.GA6656@us.netrek.org> <40C4AE5B.9030602@netrek.org> Message-ID: <20040608072903.GC2794@us.netrek.org> G'day Erik, Looks good. I hope you don't mine, but I've made a few minor changes. Could you test them for me? It compiles clean here. - use ERROR macro rather than fprintf() to stderr, so that LOGLEVEL can be used to control the debug output, - coding style stuff, spacing, variable names, - factorised the different queues, a new queue number variable, - included documentation in the docs/ file. -- James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- Index: docs/metaservers-HowTo =================================================================== RCS file: /home/netrek/cvsroot/Vanilla/docs/metaservers-HowTo,v retrieving revision 1.4 diff -u -r1.4 metaservers-HowTo --- docs/metaservers-HowTo 1 Mar 2000 01:31:22 -0000 1.4 +++ docs/metaservers-HowTo 8 Jun 2004 06:40:55 -0000 @@ -57,3 +57,27 @@ -- James Cameron (cameron@stl.dec.com) Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800 + + +-- + + +INL Metaservers HOWTO +by James Cameron +from work by "E. Hietbrink" on 7th June 2004 + +a) list your server twice each time, with "home." and "away." in front +of the host name (these names need not be registered, as the server +will strip the name before sending the host name to the metaserver), + +b) set the server type to I, + +c) list the appropriate ports. + +For example; + +metaserver.us.netrek.org 3521 60 120 home.nl.netrek.org I 4566 4000 open +metaserver.us.netrek.org 3521 60 120 away.nl.netrek.org I 4577 5000 open +metaserver2.us.netrek.org 3521 60 120 home.nl.netrek.org I 4566 4000 open +metaserver2.us.netrek.org 3521 60 120 away.nl.netrek.org I 4577 5000 open + Index: include/solicit.h =================================================================== RCS file: /home/netrek/cvsroot/Vanilla/include/solicit.h,v retrieving revision 1.1 diff -u -r1.1 solicit.h --- include/solicit.h 2 May 2001 02:00:19 -0000 1.1 +++ include/solicit.h 8 Jun 2004 06:41:13 -0000 @@ -2,7 +2,7 @@ #define MAXMETABYTES 2048 /* maximum number of metaservers supported */ -#define MAXMETASERVERS 3 +#define MAXMETASERVERS 4 /* minimum allowable delay between updates to metaserver */ #define META_MINIMUM_DELAY 60 -------------- next part -------------- A non-text attachment was scrubbed... Name: solicit.c.gz Type: application/octet-stream Size: 3708 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20040608/61c03e71/solicit.c.obj -------------- next part -------------- _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From Shadow.Hunter at netrek.org Tue Jun 8 13:13:54 2004 From: Shadow.Hunter at netrek.org (E. Hietbrink) Date: Wed Jan 12 00:51:02 2005 Subject: [Vanilla Devel] Metaserver listing + WQ32 idea? In-Reply-To: <20040608072903.GC2794@us.netrek.org> References: <40A3D579.7080001@netrek.org> <20040514000729.GA6656@us.netrek.org> <40C4AE5B.9030602@netrek.org> <20040608072903.GC2794@us.netrek.org> Message-ID: <40C601E2.7040208@netrek.org> James Cameron wrote: > G'day Erik, > > Looks good. I hope you don't mine, but I've made a few minor changes. > Could you test them for me? It compiles clean here. Will do. I do not mind changes, that is why I submitted them for review. Something I just thought of regarding WQ32 and all the commotion that it is causing. I subscribe to your point of view that WQ32 is working as intended but that the ghostbust detection is flawed. My current understanding of ghostbust detection is that the server lets someone ghostbust if for a defined number of ticks no ping information is received. right? During this time the server allows somehow (how?) to let the client reconnect (via a special command line option?). Could you prehaps briefly explain? otherwise i'd have to dig though the code first ;-) So if someone tried to log on from the same IP before the client is timed out he gets WQ32. No what if you do the following: if someone logs on a second time, check if the old slot has above MIN_TICKS_GHOSTBUSTED (say 10?) failed ping stats (which is still *far* below the I think 60 ticks that are necessary to do a normal ghostbust), make the server ghostbust the old slot immediately. The next thing you can do is two things: 1) Give the now opened slot to the first player from the waitqueue, or: 2) Give the slot to the WQ32 player, thus potentially bypassing people in the normal waitqueue. Personally I prefer option 2. If he actually ghostbusted, he'd like to get back in instead of joining at the end of the waitqueue. Your thoughts? All is based upon my current understanding of ghostbusting... Greetx, Erik _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanillatrek at yahoo.com Thu Jun 10 11:34:25 2004 From: vanillatrek at yahoo.com (Zach) Date: Wed Jan 12 00:51:02 2005 Subject: [Vanilla Devel] Metaserver listing + WQ32 idea? In-Reply-To: <40C601E2.7040208@netrek.org> Message-ID: <20040610163425.47548.qmail@web21101.mail.yahoo.com> It seems problems with people getting in to continuum are still persisting: http://tinyurl.com/2tor9 Why not remove the queue 32 patch until the ghostbust issue can be solved? Zach __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From quozl at us.netrek.org Fri Jun 25 03:47:18 2004 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:51:02 2005 Subject: [Vanilla Devel] Metaserver listing + WQ32 idea? In-Reply-To: <40C601E2.7040208@netrek.org> References: <40A3D579.7080001@netrek.org> <20040514000729.GA6656@us.netrek.org> <40C4AE5B.9030602@netrek.org> <20040608072903.GC2794@us.netrek.org> <40C601E2.7040208@netrek.org> Message-ID: <20040625084718.GA16066@us.netrek.org> On Tue, Jun 08, 2004 at 08:13:54PM +0200, E. Hietbrink wrote: > My current understanding of ghostbust detection is that the server lets > someone ghostbust if for a defined number of ticks no ping information > is received. right? Yes, that's kinda how it works. There's a counter that is moved by the daemon, and reset by the per-client ntserv process. Once the counter hits the limit, the daemon clears the slot. But that's the technique that is used to prevent ghost ships, it's the server's ghost buster. The term "ghostbust" is very ill-defined. From the users' perspective, the term has been used to describe simulation freeze, screen update lag, loss of client window, loss of contact, console messages, and the babes image. The server does have code in it to attempt to reconnect back to the client, over TCP. This only covers certain types of ghostbust causes, and only when such a connection will be propogated through any firewalling. Half the job of the server's ghostbust logic is there to reduce the utility of a forced death by terminating the client. If the user kills their client, we want them to die to a player ... we don't want them to simply disappear off the galactic. If we didn't want that feature, then as soon as the network connection dies we could remove the ship from the game and clear down the slot. Also, if they are carrying, or a starbase about to be ogged, we'd like to give them another chance ... it's only fair. The reconnect feature works like this; - client opens a port and listens, - client calls the server, makes connection, passes the listening port number, - play ensues, - network link broken by some temporary routing problem, endpoints close, - server calls client on client's listening port, - connection is re-established, further play ensues. Therefore, it depends on two critical factors that are not very true nowadays; a) that the server is informed by ICMP or TCP RST that the connection must close due to some network problem, b) that the client is reachable by return connection from the server. Without (a), the server won't initiate the process. The situations it does not cover are; - total IP packet loss between client and server, such as is caused by temporary internet route hop failures, - total IP packet loss, such as is caused by dial-up user disconnection, - reconnection of a consumer ADSL service with a new IP address. > No what if you do the following: if someone logs on a second time, check > if the old slot has above MIN_TICKS_GHOSTBUSTED (say 10?) failed ping > stats (which is still *far* below the I think 60 ticks that are necessary > to do a normal ghostbust), make the server ghostbust the old slot > immediately. That sounds appealing. I'd be happy to give that a try; once I understand the change and the impact. > The next thing you can do is two things: > 1) Give the now opened slot to the first player from the waitqueue, or: > 2) Give the slot to the WQ32 player, thus potentially bypassing people > in the normal waitqueue. > > Personally I prefer option 2. If he actually ghostbusted, he'd like to > get back in instead of joining at the end of the waitqueue. I agree, option 2 is more appropriate; the user did not intend to loss his connection. But I don't want to make self immolation in third space easier. ;-) -- 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