Randy Cassidy? I need your help!

Dear Mr. Cassidy, I need your help with my GPL network utility called GPLProxy. You have probably never heard of it as it was released in a beta version this year. Simply put, the Java Application acts as an intermediate step between a client and a server, and records all of the network traffic (UDP packets) from the server to the client. This allows the application to retransmit the packets to a number of other clients who are tricked into believing the application is a genuine server. The effect is that a (theoretically limitless) number of other GPL clients can see exactly the same as the original one without being able to interact with the real server. The application can handle different latencies and some other stuff quite well, and it is fairly good at doing what it is supposed to do. However, due to the nature of my method, retransmitting server packets, all of "viewers" receive their data with a delay equal to the delay between their connection to the GPLProxy and the connection of the real client. Eg. if they connect 10 mins. later, they will see everything 10 mins. after it really happened. I know that somehow the network code is very robust and by testing I can see that if I skip a number of packets, the client will carry on as if nothing had happened which would be just fine except for one little detail: A lot of driver/car/race information is lost! I have figured out that somehow the GPL code transmits race data (eg. lap times, names, standings, etc) instead of car data at various fixed(?) intervals. I think that by sending just these special packets and otherwise skipping ahead, I would be able to make my application "Live-ish", but I have been unable to identify these packets with my packet sniffer. Now my question to you, Mr. Cassidy, is whether you would be willing to share with me a bit of information on how to identify the race information packets? If you are unable or unwilling to do so, I would understand and just carry on with my tedious packet analysis. If you should decide to reply by email, I promise you to keep your address confidential. Some more background on GPLProxy can be found here: http://www.racesimcentral.com/features/gplproxy/gplproxy1.htm Sincerely yours, Jens H. Kruuse jens.h (at) kruuse.dk

Attn Randy Cassidy - We need a CART sim!!

I knew you were going to say that , even before I clicked the link hehe, but you are correct CART, CART, CART Edward "TRUSRS85" <[email hidden]> wrote in message news:[email hidden]... > Attn Randy Cassidy - We need a CART sim!!

Sell CART stock short and you will be able to afford to buy Papy from Sierra and build that CART sim ;) -- Scott B. Husted PA-Scott http://www.Husted.cc "TRUSRS85" <[email hidden]> wrote in message news:[email hidden]... > Attn Randy Cassidy - We need a CART sim!!

"Edward C" <[email hidden]> wrote in message news:xDL_7.7157$[email hidden]... > I knew you were going to say that , even before I clicked the link hehe,but > you are correct > CART, CART, CART > > Edward And frankly - with the N4 / N4 '02 engine - it wouldnt take very long to make a Cart sim either - infact it's more of a car and track update than a whole new game They ahve the licence - they have the gfx, phys and 'netplay engines - if they dont work on a Cart sim between now and doing YET ANOTHER BLOODY SPAZCAR SIM then either Papy or Sierra need to get SHOT Doug

On Tue, 8 Jan 2002 19:01:57 +0100, "Jens H. Kruuse" <[email hidden]> wrote: ...

Quoted text (9 lines)

>I know that somehow the network code is very robust and by testing I can see >that if I skip a number of packets, the client will carry on as if nothing had >happened which would be just fine except for one little detail: A lot of >driver/car/race information is lost! I have figured out that somehow the GPL >code transmits race data (eg. lap times, names, standings, etc) instead of car >data at various fixed(?) intervals. I think that by sending just these special >packets and otherwise skipping ahead, I would be able to make my application >"Live-ish", but I have been unable to identify these packets with my packet >sniffer.

The packets are so-called reliable packets (retransmitted when it looks the client didn't get them). Perhaps they can be discovered by looking for similar packets, esp. in bad network conditions, since the resent ones will look the same. On the other hand, in a nice network library, other (less important) message will often piggyback on the UDP message, as more than one message is generally sent in one packet. Although even there you'd probably see the more important data in the front of the packet. In my sim for example, multiple smaller messages are packed into 1 packet, and then sent. So reliable and unreliable message may be mixed, and it would be quite hard to pick them out without knowing the size of each message inside the packet. One thing to option for might be to make every packet a reliable one (maybe even turning it into TCP/IP, yugh). Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/