Seeing how USB has been able to cope with multi-channel MIDI in professional audio production for years, and even multi-channel high quality audio in later years, being able to update an RPM gauge shouldn't be much of a problem in terms of speed, logically.
This consumer level audio interface can record 24bit/96kHz stereo sound in realtime, it's not possible for this thing to have a large enough internal buffer for lengthy recordings, so that's ~288 KB/s thru USB.
Ask your administrator what he's on about, a server can't refuse your connection based on sniffing out that you're behind NAT. It's all pretty strange really, logically, you should be able to connect to (almost) everything, or if there's a network problem - nothing, not ~60% of servers.
Since there's no network config on behalf of an LFS server, and you can connect to certain servers, everything is basically working.
I've opened a server on a very non-standard port, see if you can connect to "NAT?", Blackwood RallyX/FO8.
Edit: @Becky, i really doubt the master server use anything other then pure IP's, there's really no reason to use hostnames.
A cliché of course, but it's the setup. Also, speed brings stability in the RA, at times it's way more stable then, for example, the FZ5 or XRT. I start with a setup featuring massive understeer, and dial out just enough of it to properly get round the track in question.
The thing often missing in legal torrent situations is a high speed server joining in, even if the idea is to bypass the need of a server, torrents can start out very slow even if there are reasonably high speed peers and seeds, a server which completely disregards tit-for-tat will initally speed up traffic significantly, and as seeds increase its load will of course drop.
I figured out the unpack types by trial and error, what i use is:
char: just grab raw (plain substr).
byte: signed char "c".
word: unsigned short "S", note that input must be 2 bytes.
short: signed short "s".
int: signed integer "i".
MSHT: 3x signed char "c", skipping thousands since they're never present.
The other types listed in InSim.txt that i haven't included are AFAIK only present in packets not needed in server handling, float, for example, is only used to present replay speed and FOV.
That's pretty similar to my thingie, tho mine isn't hardcoded like that.
Anyway, you're not using substr correctly, the parameters are string, start offset, length. You're thinking string, start offset, end offset, which isn't right.
<?php $LAP['UName'] = substr( $packet, 4, 28); ?>
Will actually read 28 bytes from offset 4, not the range 4 - 28.
I've no idea why, i RAR'ed the files using "Store" which results in no compression at all, since there's no point in compressing something that's already heavily compressed.