From livecams at freecam.net Fri May 2 17:42:08 2003 From: livecams at freecam.net (livecams@freecam.net) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] hey its me again...  i1b9 Message-ID: <200305022242.h42Mg8X15731@host2.rsinternet.com> Someone submitted some info via your web-form on the 2-May-2003. It is as follows; recipient = webmaster@elpub.org,fp6iepnews@ketlux.demon.co.uk,joseph.kirsch@cec.eu.int,pascal.jacques@cec.eu.int,salvador.gurrera@iua.upf.es,aliciab@texas.net,loganar@aol.com,vanilla-devel@us.netrek.org,2ddevel@us.netrek.org,quozl@us.netrek.org, subject = hey its me again...  i1b9 email = livecams@freecam.net = LIVE SLUTS BROADCASTING FROM THERE DORMROOM CLICK HERE NOW, DONT KEEP THESE HORNY SLUTS WAITING .. Hi ppl, I managed to get hold of an UltraSparc 5 and have installed NetBSD 1.6.1. Naturally the next deamon after sshd and apache was netrek ;-) So I just downloaded the Vanilla-2.9pl8 server sources and tried to compile it. I had to make two changes to make it work. Since I am new to the whole vanilla sources I just list my problem and fix and let you ppl propose the real solution. Note that they're minor issues.. 1) Since I run the UltraSparc as a headless machine I did not bother to install X11 libraries and such. So I ran into: xsg/x11window.c:11: X11/Xlib.h: No such file or directory xsg/x11window.c:12: X11/Xutil.h: No such file or directory What I did was adapt the Makefile to not build the XSG server management tool. 2) On NetBSD 1.6.1 sun sparc64, man sigaction shows that no sa_sigaction element exists, so I commented out its usage in update.c tools/update.c: In function `no_zombies': tools/update.c:201: structure has no member named `sa_sigaction' After these two fixes all compiled well and I was enjoying a <1ms lag! Yes! ;-) Now my question. I'm putting this machine behind a firewall. What UDP/TCP ports should I open to make it world accessible? I saw an earlier post by Dave about the INL server ports. Is there a document/list somewhere? problem is I cant test it myself from outside the firewalled network. Thx. Greetx, Erik (Shadow Hunter) _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From David.Watson at team17.com Wed May 14 10:40:45 2003 From: David.Watson at team17.com (David Watson) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] Firewalling a netrek server In-Reply-To: <3EC25C1A.6020501@netrek.org> Message-ID: <5.2.0.9.0.20030514163201.024edeb8@mailgate.team17.com> If you are doing NAT then you have to disable RSA, I havnt looked into that... iptables rules are below, you should be able to grab ports from them. My servers fail to contact the metaservers the server must be able to do dns (udp and tcp 53) auth (tcp 113) and whatever game ports that you run on. not my forwarding rule actually allow all ports over 1024 in an attempt to get metaserver working (possibly incoming udp connections 1024 + needed for portswap?). These rules were under construction when I decided - good enough Dave $IPTABLES -N verify_netrekout_for $IPTABLES -N verify_netrekin_for # Allow serving of game server ports to world $IPTABLES -A verify_netrekout_for -p TCP --sport 113 -j tcp_verify $IPTABLES -A verify_netrekout_for -p TCP --sport 2592 -j tcp_verify $IPTABLES -A verify_netrekout_for -p UDP --sport 2592 -j ACCEPT $IPTABLES -A verify_netrekout_for -p TCP --sport 2593 -j tcp_verify $IPTABLES -A verify_netrekout_for -p UDP --sport 2593 -j ACCEPT $IPTABLES -A verify_netrekout_for -p TCP --sport 4566 -j tcp_verify $IPTABLES -A verify_netrekout_for -p UDP --sport 4566 -j ACCEPT $IPTABLES -A verify_netrekout_for -p TCP --sport 4577 -j tcp_verify $IPTABLES -A verify_netrekout_for -p UDP --sport 4577 -j ACCEPT $IPTABLES -A verify_netrekout_for -p TCP --sport 4000 -j tcp_verify $IPTABLES -A verify_netrekout_for -p UDP --sport 4000 -j ACCEPT $IPTABLES -A verify_netrekout_for -p TCP --sport 5000 -j tcp_verify $IPTABLES -A verify_netrekout_for -p UDP --sport 5000 -j ACCEPT # Metaserver and client verification $IPTABLES -A verify_netrekout_for -p TCP --dport 1024: -j tcp_verify $IPTABLES -A verify_netrekout_for -p UDP --dport 1024: -j ACCEPT # Allow serving of game server ports to world $IPTABLES -A verify_netrekin_for -p TCP --dport 113 -j tcp_verify $IPTABLES -A verify_netrekin_for -p TCP --dport 2592 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --dport 2592 -j ACCEPT $IPTABLES -A verify_netrekin_for -p TCP --dport 2593 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --dport 2593 -j ACCEPT $IPTABLES -A verify_netrekin_for -p TCP --dport 4566 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --dport 4566 -j ACCEPT $IPTABLES -A verify_netrekin_for -p TCP --dport 4577 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --dport 4577 -j ACCEPT $IPTABLES -A verify_netrekin_for -p TCP --dport 4000 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --dport 4000 -j ACCEPT $IPTABLES -A verify_netrekin_for -p TCP --dport 5000 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --dport 5000 -j ACCEPT $IPTABLES -A verify_netrekin_for -p UDP --dport 1024: -j ACCEPT # Metaserver $IPTABLES -A verify_netrekin_for -p TCP --sport 3521 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --sport 3521 -j ACCEPT $IPTABLES -A verify_netrekin_for -p TCP --sport 3530 -j tcp_verify $IPTABLES -A verify_netrekin_for -p UDP --sport 3530 -j ACCEPT _______________________________________________ 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 May 14 17:52:05 2003 From: quozl at us.netrek.org (James Cameron) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] Small compilation bugfix for NetBSD 1.6.1 on sparc64 + other questions In-Reply-To: <3EC25C1A.6020501@netrek.org> References: <3EC25C1A.6020501@netrek.org> Message-ID: <20030514225205.GB15660@us.netrek.org> On Wed, May 14, 2003 at 05:09:14PM +0200, Erik Hietbrink wrote: > [...] just list my problem and fix and let you ppl propose the > real solution. ;-} Gee thanks. > xsg/x11window.c:11: X11/Xlib.h: No such file or directory > xsg/x11window.c:12: X11/Xutil.h: No such file or directory > What I did was adapt the Makefile to not build the XSG server management > tool. Noted in PROJECTS file already, by Tom. I guess configure should detect no X libraries, and skip the xsg build. > 2) On NetBSD 1.6.1 sun sparc64, man sigaction shows that no > sa_sigaction element exists, so I commented out its usage in update.c > tools/update.c: In function `no_zombies': > tools/update.c:201: structure has no member named `sa_sigaction' Again, configure should detect lack of sa_sigaction, and so alter the compile of tools/update.c ... added to PROJECTS. > Now my question. I'm putting this machine behind a firewall. What UDP/TCP > ports should I open to make it world accessible? I saw an earlier post by > Dave > about the INL server ports. Is there a document/list somewhere? problem is I > cant test it myself from outside the firewalled network. Thx. No, there is no documented list that I know of. We have a list that works for Continuum, but only Bob has it. Once you get it working, pass it to me and I'll add it as CVS docs/sample_iptables ... I'm tempted to just insert Dave's, but I'd like someone to test it independently. -- 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 vanilla-devel at us.netrek.org Wed May 14 17:52:38 2003 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] CVS update: Vanilla Message-ID: <200305142252.h4EMqc131795@swashbuckler.real-time.com> Date: Wednesday May 14, 2003 @ 17:52 Author: cameron Update of /home/netrek/cvsroot/Vanilla In directory swashbuckler.real-time.com:/var/tmp/cvs-serv31792 Modified Files: PROJECTS Log Message: **************************************** Index: Vanilla/PROJECTS diff -u Vanilla/PROJECTS:1.98 Vanilla/PROJECTS:1.99 --- Vanilla/PROJECTS:1.98 Mon Dec 9 05:31:48 2002 +++ Vanilla/PROJECTS Wed May 14 17:52:38 2003 @@ -1,7 +1,9 @@ -$Id: PROJECTS,v 1.98 2002/12/09 11:31:48 cameron Exp $ +$Id: PROJECTS,v 1.99 2003/05/14 22:52:38 cameron Exp $ List of things to do in the future + + - tools/update.c sa_sigaction not present on NetBSD. [Hietbrink] - 'transwarp 0 off' to prevent slot 0 from transwarping. [Swasey] _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From vanilla-devel at us.netrek.org Wed May 14 17:55:00 2003 From: vanilla-devel at us.netrek.org (Vanilla CVS Development) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] CVS update: Vanilla/docs Message-ID: <200305142255.h4EMt0Z31806@swashbuckler.real-time.com> Date: Wednesday May 14, 2003 @ 17:55 Author: cameron Update of /home/netrek/cvsroot/Vanilla/docs In directory swashbuckler.real-time.com:/var/tmp/cvs-serv31803 Added Files: sample_iptables Log Message: add first draft, subject to independent verification **************************************** _______________________________________________ vanilla-devel mailing list vanilla-devel@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-devel From Monika.von-Stetten at gmx.de Fri May 23 17:23:52 2003 From: Monika.von-Stetten at gmx.de (Monika von Stetten) Date: Wed Jan 12 00:50:44 2005 Subject: [Vanilla Devel] =?iso-8859-1?Q?Gesch=E4ftsgelegenheit!!?= Message-ID: <000001c3217a$288a39e0$fe79a8c0@Peter> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 5675 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/netrek-dev/attachments/20030524/422c626a/attachment.jpe From xyzzy at speakeasy.org Fri May 2 11:15:51 2003 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:51:47 2005 Subject: [Vanilla List] Real network utilization stats for an INL game In-Reply-To: <20030430141637.A24508@genocide.netrek.org> Message-ID: On Wed, 30 Apr 2003, Dave Ahn wrote: > David Watson contributed some network utilization stat graphs for a real > INL game held recently at eurotwinks.netrek.org. As there have been > some discussion in the past about how much bandwidth Netrek needs, this > provides some useful data which might suggest that our earlier numbers > might need to be upped. The graphs are available as part of the stats > at the below URL. I'd really like to see the packets per second on a per player basis for both input and output, in terms of say one second peak. I've always wondered what the auto-firing borgs that are popular now do to network bandwidth. If the client sends 100 fire phaser requests per second, does the server respond with 100 "phaser not ready" messages? Does spamming the server with change course packets cause other players' ntservs to not get any cputime? netrek doesn't request any real-time scheduling, so there's no reason the OS won't decide to sacrifice latency for throughput when scheduling. _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From doosh at inl.org Fri May 2 11:35:42 2003 From: doosh at inl.org (Tom Holub) Date: Wed Jan 12 00:51:47 2005 Subject: [Vanilla List] Real network utilization stats for an INL game In-Reply-To: ; from xyzzy@speakeasy.org on Fri, May 02, 2003 at 09:15:51AM -0700 References: <20030430141637.A24508@genocide.netrek.org> Message-ID: <20030502093542.A75422@inl.org> On Fri, May 02, 2003 at 09:15:51AM -0700, Trent Piepho wrote: > On Wed, 30 Apr 2003, Dave Ahn wrote: > > David Watson contributed some network utilization stat graphs for a real > > INL game held recently at eurotwinks.netrek.org. As there have been > > some discussion in the past about how much bandwidth Netrek needs, this > > provides some useful data which might suggest that our earlier numbers > > might need to be upped. The graphs are available as part of the stats > > at the below URL. > > I'd really like to see the packets per second on a per player basis for both > input and output, in terms of say one second peak. I've always wondered what > the auto-firing borgs that are popular now do to network bandwidth. If the > client sends 100 fire phaser requests per second, does the server respond with > 100 "phaser not ready" messages? Does spamming the server with change course > packets cause other players' ntservs to not get any cputime? netrek doesn't > request any real-time scheduling, so there's no reason the OS won't decide to > sacrifice latency for throughput when scheduling. You only get one update per tick. -Tom _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From mark at mark.mielke.cc Sat May 3 23:28:18 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:51:47 2005 Subject: [Vanilla List] Real network utilization stats for an INL game In-Reply-To: <20030502093542.A75422@inl.org> References: <20030430141637.A24508@genocide.netrek.org> <20030502093542.A75422@inl.org> Message-ID: <20030504042818.GA26688@mark.mielke.cc> On Fri, May 02, 2003 at 09:35:42AM -0700, Tom Holub wrote: > On Fri, May 02, 2003 at 09:15:51AM -0700, Trent Piepho wrote: > > I'd really like to see the packets per second on a per player basis > > for both input and output, in terms of say one second peak. I've > > always wondered what the auto-firing borgs that are popular now do > > to network bandwidth. If the client sends 100 fire phaser requests > > per second, does the server respond with 100 "phaser not ready" > > messages? Does spamming the server with change course packets > > cause other players' ntservs to not get any cputime? netrek > > doesn't request any real-time scheduling, so there's no reason the > > OS won't decide to sacrifice latency for throughput when > > scheduling. > You only get one update per tick. Warning messages, for example, are sent immediately, often as packets on their own. I expect that 40 phaser requests would result in 39+ warning packets as Trent is theorizing. That said, 39+ packets isn't much unless you are connecting to netrek through a dialup modem... Trent: 'spamming the server' would only allow you to grab cpu time reserved for your ntserv process. Eventually, your process gets swapped out, and everybody else gets a turn. Could this cause noticable lag? Maybe, but probably not. Each ntserv process is likely limited to a time slice of less than 0.1 seconds if it isn't calling system calls, and less if it is doing read()/write() operations, especially if the write() blocks because the outgoing system buffer is full (something else I assume would eventually happen if the 'spamming' is resulting in numerous response packets). mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From xyzzy at speakeasy.org Sun May 4 04:46:26 2003 From: xyzzy at speakeasy.org (Trent Piepho) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] Real network utilization stats for an INL game In-Reply-To: <20030504042818.GA26688@mark.mielke.cc> Message-ID: On Sun, 4 May 2003, Mark Mielke wrote: > > Warning messages, for example, are sent immediately, often as packets > on their own. I expect that 40 phaser requests would result in 39+ > warning packets as Trent is theorizing. That what I expected too, but I thought that perhaps there was some kind of throttle in there that kept it from happening. A one warning per update limit of some kind. > > Trent: 'spamming the server' would only allow you to grab cpu time > reserved for your ntserv process. Eventually, your process gets swapped > out, and everybody else gets a turn. Could this cause noticable lag? There is no reaon for the OS scheduler will give every process an equal slice, or do so in a low latency manner. Linux has well known problems with processes getting starved in heavy IO loads. For instance, I have a system at work that has five RAID arrays that can do upwards of 70 MB/sec apiece. If I copy a huge file from one to another, running ls on a directory with just a dozen files in it takes 10 to 20 seconds. > Maybe, but probably not. Each ntserv process is likely limited to a time > slice of less than 0.1 seconds if it isn't calling system calls, and less Think about this, .1 seconds is 100 ms. There are 16 players. If four of those players use packet spam borgs and suck up 100 ms a piece, then that's 400 ms added to your lag. Quite a bit. _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list From mark at mark.mielke.cc Sun May 4 16:24:33 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed Jan 12 00:51:48 2005 Subject: [Vanilla List] Real network utilization stats for an INL game In-Reply-To: References: <20030504042818.GA26688@mark.mielke.cc> Message-ID: <20030504212433.GA12243@mark.mielke.cc> On Sun, May 04, 2003 at 02:46:26AM -0700, Trent Piepho wrote: > On Sun, 4 May 2003, Mark Mielke wrote: > > Maybe, but probably not. Each ntserv process is likely limited to a time > > slice of less than 0.1 seconds if it isn't calling system calls, and less > Think about this, .1 seconds is 100 ms. There are 16 players. If four of > those players use packet spam borgs and suck up 100 ms a piece, then that's > 400 ms added to your lag. Quite a bit. They would only get 0.1 seconds if the ntserv process was doing pure CPU. If it blocked on a system call at all, as would be expected from a 'packet spam' attempt, the process would be swapped out earlier. Also, users of a recent version of the Alan Cox kernels benefit from the low latency patches, as well as having the system scheduler update up to 1000 times a second instead of the traditional 100 times a second. It simply isn't likely, unless you could come up with a way of causing each packet you send to generate a substantial amount of CPU activity. As it is, packets like "change direction to 34" are only a few bytes long, take almost no time to process, and are not candidates for 'packet spamming'. If you are truly worried about one user sending so many packets to the interface that they block up the interface on the server side, I suppose this might be possible. However, they could do the same thing with a SYN flood, or some other more effective method than Netrek packets... The most expensive packet operation I can think of for Netrek is 'request full update', and I believe that this request is throttled. The second most expensive packet operation I can think of is the message packet, as one message may result in messages being sent to several clients. This request is also throttled. So what packet would you use? mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ _______________________________________________ vanilla-list mailing list vanilla-list@us.netrek.org https://mailman.real-time.com/mailman/listinfo/vanilla-list