On Wednesday, January 29, 2003, at 07:34 PM, Michael Adams wrote:
> Anyway, networking is working! No out-of-sync errors,
> and both sides could gather and see each other even
> with out join-by-IP. No boatyness or pea-soup, though
> there were a few pauses in game. The pauses always
> happened on both computers at the same time, and
> typicaly lasted 2-4 seconds. The "game time" that
> elapsed during a pause would be less than a second.
> Both machines stayed in sync even after the pause.
Interesting. Is there anything about your network setup, or other tasks
running on the machines, that might account for this? You might try
enabling verbose logging on the Windows machine (see another post
somewhere) and check the "PROFILE FOR TMTASK" stuff, particularly to see
whether the 33ms-periodic task has any weird characteristics (lots of
late calls, or a DriftMax of more than a couple hundred ms, etc.). The
40ms task usually does have some weird-looking stuff, mostly because
it's constantly being reset (every time the machine gets an
acknowledgement packet from the other machine).
> Overall I would say networking worked exactly like
> it's supposed to. I belive a standing ovation is in
> order for all those who contributed getting networking
> to work especially Woody.
I do have to credit Christian Bauer for taking some first steps in that
direction, long ago, and thus giving me someplace to start from.
Thanks also to various people who have tested builds and provided
But aside from that I'll happily drink up the praise ;) keep it
coming!... ;) ;) (hint!: SDL Postgame Carnage Report ;) )
> One thing that people do need to be aware of is that
> Aleph doesn't play nicely if a firewall is blocking
> the connection. (That was the cause of all my problems
> earlyer) It will hang when the gather-er attempts to
> add the other person. It would be nice if the game
> was a little more graceful about that (maybe a dialog
> that asks the user to dissable any firewalls), but
> that's the only thing that needs much work. To help
> get around this for now, the ports that Aleph uses
> should be documented in the readme and in the FAQ.
Interesting. Yeah I should make sure there is some sort of 'max
retries' thing on that establish-the-connection stuff, because you're
right, this should "fail nice" if there's a problem like this.
And yeah the port numbers should be listed somewhere prominent. I'll
post them again for everyone's convenience. UDP 15367, UDP 4226, TCP
In particular the sequence of steps currently taken in getting a netgame
going is: (this overview may help people troubleshooting their network
link-up, based on where things are going wrong. 'tcpdump' is also very
useful in seeing which behaviors are and aren't happening correctly.
Maybe this stuff should be included also with the ports, in a 'getting
networking to work' section somewhere.)
1. Gatherer broadcasts "FIND" packet to and from UDP 15367.
2. Joiner (either in response to hearing FIND packet or using
Join-By-Address) sends Gatherer a "HAVE" packet to and from UDP 15367.
(Gatherer shows player in "Players on Network" box upon receiving a HAVE
3. When Gatherer tries to add the player, Gatherer establishes a TCP
connection to the joiner at port 4226. (I'm not sure whether the TCP
connection comes _from_ 4226, FWIW.) This tells the joiner he can
join. If it works, the Joiner shows up in the Gatherer's 'Players in
Game' box, and Joiner sees players in his 'Players in Game' box. That
connection is closed. More TCP connections are subsequently established
and closed, just like this first one: some send the joiner pregame
gatherer-to-joiners chat messages. Some tell the joiner about other
players joining. Some tell the joiner the game's going to start. Some
send the joiner the map and physics model etc. (during which, the
gatherer and joiner have dialog boxes on their screens indicating that
the "environment information" is being transmitted).
4. After all that, when it's time to start the game proper (NetSync()
is called), the Gatherer sends from UDP 4226 to his upring neighbor
(some joining machine) at UDP 4226.
5. The upring neighbor sends back an ACK to and from UDP 4226.
6. When the ring packet gets all the way back around to the gatherer,
the game is allowed to start.
So if the gatherer is trying to add a player and it's hanging forever,
it must be the case that that connection to the joiner's TCP port 4226
isn't working. The problem may be that my connection-establishment code
does not properly give up after enough failed attempts. (Not sure,
haven't reviewed it yet.) Oops.
The above is somewhat of a simplification. And yes, even from that
little bit, it's clear there are many ways the scheme could be
improved. Well, it works as it is (which is essentially how Bungie did
it in AppleTalk); overhauling it has not been a high priority for me. :)
> I wasn't able to test mic b/c IIRC that's Win32 only
> right now, and I was running Win32 to Carbon. When I
> used the mic though, it didn't crash or anything. So
> either the mic is dissabled in my build (oops) or
> Carbon was ignoring those packes like it should.
This came up because although the mic works on my machine using my own
privately-produced build, it does not work when using Michael's released
FWIW I generally have fairly old SDK's (for DirectX etc. - I *might*
have the DirectX 5 SDK) whereas I think Michael has newer ones. So
maybe somehow building against the newer DirectSoundCapture SDK is
making things happen differently. (?) To be honest I'm not even sure
what version of DirectX [runtime] I've got on that machine. Heh heh.
Whichever one had an 'a' release maybe? (Is that 6.0a? 7.0a?) Anyway
if building against a newer SDK turns out to be the problem, maybe a
strategic #define somewhere could build against the oldest DirectX
actually required, instead of the newest available? ;) (Note that uses
of DirectX for sound playback, drawing, etc. are wrapped in SDL, which
is built separately, so building A1 against an older DirectX SDK would
not restrict A1's abilities in these other areas.)
Note that the SDL version on Mac OS X (like any other SDL version) can
receive and play back (but not yet transmit) network microphone data.
Before sending my fixes, I did verify that the Carbon version correctly
ignores SDL-style network audio packets (though a patch was needed - and
made - to make it ignore gatherer-to-joiners pregame chat messages -
they're ignored since there's no UI provided for them). And even on my
machine using the release build, where the microphone doesn't work...
well it just doesn't work, there are no worse problems created. So
anyway, no real surprises there. :)
BTW in which of M1, M2, or Moo did the network microphone actually
work? I seem to recall that, most of the time, it didn't... but maybe
that was just the hardware we had back then. Anyone remember the
various 'look down' bugs, also? :) Those seemed to stick around way
longer than one would expect, IIRC. We're lucky A1 doesn't have them.