Race Sim Central
Rec.Autos.Simulators Archive

Cassidy! GPL: Time-outs, protocols and ports

15 posts by 9 people · 01 Jun 2001 14:35 UTC - 07 Jun 2001 00:32 UTC

Asgeir Nesoen 01 Jun 2001 14:35 UTC#181377
I have two GPL servers sitting on a university network in Oslo (with enormous amounts of bandwidth available), and I have had ensuing problems with clients getting time-outs when connecting. A few facts: Computer 1 (1.Vege): Dell Dimension Precision 220 PIII 700Mhz Computer 2 (2.Vege): Dell Optiplex GX1 PII 350 Mhz How a client and server communicate: 1) The client sends UDP: "I am a Papyrus client" to port 32766 on server 2) The server answers, UDP "I am a Papyrus server" to port 32767 on client with the assigned port number for the client to use 3) The client sends UDP: "I am a Papy client" to the newly assigned port on the server, in this case 32778 4) The server responds, UDP "I am a Papy server" to port 32767, coming from server port 32778 5) Then info on passwords, tracks and things like that is passed back and forth between the client port (32766) and the designated client's port on the server (32778 in this case) and connection is established When I get time-outs, the server fails to send a new handshaking packet from the newly assigned port, it just continues to send from the old port (32766). After 10 tries, the client gets a "destination unreachable". After 5 seconds of this, the client says: Time-out and blah-blah... It seems like the server doesn't open the port that it designated for the client in question, and I would desperately like to know why. Is there any setting in Windows that stops too many UDP ports to be opened at one time? Is there any reason for the server NOT to accept the UDP packets coming in on the designated port? I mean, the server sends out the new port on which the client is supposed to send packets too, but this port is closed. I would guess that the UDP port in question simply is closed both ways. Anyone got any idea? Randy Cassidy, for instance? Is there any way I can make the connecting process to work smoothly? Time-out values?What reasons can there be for the server not being able to receive UDP-packets on the port it recently designated? How much time does a window app need to readying reading on a new UDP port? I'd love to find out why, because this problem has buggered me for so long now, and I'd love to exploit my huge connection to the benefit of the GPL society... Now, if mr. Cassidy was here.... :-) ---Asgeir--- Observations: The ping rates are very low, and no errors (but this is ICMP based, so it is a different story, I know), irrespective of any server load Once the clients get in (after sometimes inumberable failed attempts), the connection is *very* good, and totally glitch free Sometimes, I get in without a hitch, other times, I need to try 30 times, and I am on dial-up inside the university network... Computer speed makes NO difference in the amounts of timeouts Different OS's make no difference (95, 98) Different netcards make no difference There is no limiting or admission checking of UDP packets on the university network
Just so you know I am also noticing this behavior, when trying to change the port numbers from that which GPL or VROC wnat to use, it ignores those settings and tries to connect with the defaults. I have three servers running at my University with no problems, it is when I try to place them behind the firewall that problems arise. SLG Asgeir Nesoen <[email hidden]> wrote:
Quoted text (62 lines)>I have two GPL servers sitting on a university network in Oslo (with >enormous amounts of bandwidth available), and I have had ensuing >problems with clients getting time-outs when connecting. > >A few facts: >Computer 1 (1.Vege): Dell Dimension Precision 220 PIII 700Mhz >Computer 2 (2.Vege): Dell Optiplex GX1 PII 350 Mhz > >How a client and server communicate: >1) The client sends UDP: "I am a Papyrus client" to port 32766 on server > >2) The server answers, UDP "I am a Papyrus server" to port 32767 on >client with the assigned port number for the client to use >3) The client sends UDP: "I am a Papy client" to the newly assigned port >on the server, in this case 32778 >4) The server responds, UDP "I am a Papy server" to port 32767, coming >from server port 32778 >5) Then info on passwords, tracks and things like that is passed back >and forth between the client port (32766) and the designated client's >port on the server (32778 in this case) and connection is established > >When I get time-outs, the server fails to send a new handshaking packet >from the newly assigned port, it just continues to send from the old >port (32766). After 10 tries, the client gets a "destination >unreachable". After 5 seconds of this, the client says: Time-out and >blah-blah... > >It seems like the server doesn't open the port that it designated for >the client in question, and I would desperately like to know why. Is >there any setting in Windows that stops too many UDP ports to be opened >at one time? Is there any reason for the server NOT to accept the UDP >packets coming in on the designated port? I mean, the server sends out >the new port on which the client is supposed to send packets too, but >this port is closed. I would guess that the UDP port in question simply >is closed both ways. > >Anyone got any idea? Randy Cassidy, for instance? Is there any way I can >make the connecting process to work smoothly? Time-out values?What >reasons can there be for the server not being able to receive >UDP-packets on the port it recently designated? How much time does a >window app need to readying reading on a new UDP port? > >I'd love to find out why, because this problem has buggered me for so >long now, and I'd love to exploit my huge connection to the benefit of >the GPL society... Now, if mr. Cassidy was here.... :-) > >---Asgeir--- > >Observations: >The ping rates are very low, and no errors (but this is ICMP based, so >it is a different story, I know), irrespective of any server load >Once the clients get in (after sometimes inumberable failed attempts), >the connection is *very* good, and totally glitch free >Sometimes, I get in without a hitch, other times, I need to try 30 >times, and I am on dial-up inside the university network... >Computer speed makes NO difference in the amounts of timeouts >Different OS's make no difference (95, 98) >Different netcards make no difference >There is no limiting or admission checking of UDP packets on the >university network > >
(All spelling errors are intentional and are there to show new and improved ways of spelling old words. Grammatical errors are due to too many English classes/teachers)
I've only seen this occasionally (never on a reproducible basis), so there could be something else going on, but this type of thing can be triggered by a bug in our code. I found/fixed it while working on N4. I don't recall the particulars, but it was some timing related, state transition thing where one end was still expecting those ID strings when the other end had stopped sending them (or some such). I can't think of any sure way to work around it. You could maybe try changing the client_send_every/server_send_every settings so that the server is sending more often than the client, or vice versa. 2 and 3 are the only useful values outside of a really small LAN (where 1 might also work). Randy "Asgeir Nesoen" <[email hidden]> wrote in message news:[email hidden]...> I have two GPL servers sitting on a university network in Oslo (with
Quoted text (61 lines)> enormous amounts of bandwidth available), and I have had ensuing > problems with clients getting time-outs when connecting. > > A few facts: > Computer 1 (1.Vege): Dell Dimension Precision 220 PIII 700Mhz > Computer 2 (2.Vege): Dell Optiplex GX1 PII 350 Mhz > > How a client and server communicate: > 1) The client sends UDP: "I am a Papyrus client" to port 32766 on server > > 2) The server answers, UDP "I am a Papyrus server" to port 32767 on > client with the assigned port number for the client to use > 3) The client sends UDP: "I am a Papy client" to the newly assigned port > on the server, in this case 32778 > 4) The server responds, UDP "I am a Papy server" to port 32767, coming > from server port 32778 > 5) Then info on passwords, tracks and things like that is passed back > and forth between the client port (32766) and the designated client's > port on the server (32778 in this case) and connection is established > > When I get time-outs, the server fails to send a new handshaking packet > from the newly assigned port, it just continues to send from the old > port (32766). After 10 tries, the client gets a "destination > unreachable". After 5 seconds of this, the client says: Time-out and > blah-blah... > > It seems like the server doesn't open the port that it designated for > the client in question, and I would desperately like to know why. Is > there any setting in Windows that stops too many UDP ports to be opened > at one time? Is there any reason for the server NOT to accept the UDP > packets coming in on the designated port? I mean, the server sends out > the new port on which the client is supposed to send packets too, but > this port is closed. I would guess that the UDP port in question simply > is closed both ways. > > Anyone got any idea? Randy Cassidy, for instance? Is there any way I can > make the connecting process to work smoothly? Time-out values?What > reasons can there be for the server not being able to receive > UDP-packets on the port it recently designated? How much time does a > window app need to readying reading on a new UDP port? > > I'd love to find out why, because this problem has buggered me for so > long now, and I'd love to exploit my huge connection to the benefit of > the GPL society... Now, if mr. Cassidy was here.... :-) > > ---Asgeir--- > > Observations: > The ping rates are very low, and no errors (but this is ICMP based, so > it is a different story, I know), irrespective of any server load > Once the clients get in (after sometimes inumberable failed attempts), > the connection is *very* good, and totally glitch free > Sometimes, I get in without a hitch, other times, I need to try 30 > times, and I am on dial-up inside the university network... > Computer speed makes NO difference in the amounts of timeouts > Different OS's make no difference (95, 98) > Different netcards make no difference > There is no limiting or admission checking of UDP packets on the > university network > >
Well Randy, From my experience, the problem is eeriely repeatable with this set of servers. The infuriating bit is it doesn't effect everybody equally (sometimes I can connect whenever and last night it took me 40 tries) and some servers (Eldred's for example) don't seem to suffer at all. This had us thinking there was an external factor we might influence. Would be helpfull if you'd refresh your memory on this one. Jan. =--- Randy Cassidy wrote...
Quoted text (13 lines)> I've only seen this occasionally (never on a reproducible basis), > so there could be something else going on, but this type of thing > can be triggered by a bug in our code. I found/fixed it while > working on N4. I don't recall the particulars, but it was some > timing related, state transition thing where one end was still > expecting those ID strings when the other end had stopped sending > them (or some such). I can't think of any sure way to work around > it. You could maybe try changing the client_send_every/server_send > _every settings so that the server is sending more often than the > client, or vice versa. 2 and 3 are the only useful values outside > of a really small LAN (where 1 might also work). > > Randy
I wonder if OS has some cause? I am using Win98 for all of my GPL servers. What is everyone else using? Also using DX8.0 SLG "Jan Verschueren" <[email hidden]> wrote:
Quoted text (28 lines)>Well Randy, > >From my experience, the problem is eeriely repeatable with this set of >servers. The infuriating bit is it doesn't effect everybody equally >(sometimes I can connect whenever and last night it took me 40 tries) and >some servers (Eldred's for example) don't seem to suffer at all. > >This had us thinking there was an external factor we might influence. Would >be helpfull if you'd refresh your memory on this one. > >Jan. >=--- >Randy Cassidy wrote... >> I've only seen this occasionally (never on a reproducible basis), >> so there could be something else going on, but this type of thing >> can be triggered by a bug in our code. I found/fixed it while >> working on N4. I don't recall the particulars, but it was some >> timing related, state transition thing where one end was still >> expecting those ID strings when the other end had stopped sending >> them (or some such). I can't think of any sure way to work around >> it. You could maybe try changing the client_send_every/server_send >> _every settings so that the server is sending more often than the >> client, or vice versa. 2 and 3 are the only useful values outside >> of a really small LAN (where 1 might also work). >> >> Randy > >
(All spelling errors are intentional and are there to show new and improved ways of spelling old words. Grammatical errors are due to too many English classes/teachers)
In article <[email hidden]>, [email hidden] (Steve Garrotto) writes: >I wonder if OS has some cause? I am using Win98 for all of my GPL >servers. What is everyone else using? Also using DX8.0 Win98se on 2 of them, Win2K on the 3rd. Not using DX8 on any of them, and WON'T, either. I wanted to load N4 as a server, and accidentally let it load DX8. It totally trashed my system - I had to re-format. <insert Marvin the Martian voice> That made me *very* angry... Eldred -- Dale Earnhardt, Sr. R.I.P. 1951-2001 Homepage - http://www.umich.edu/~epickett F1 hcp. +24.63...F2 +151.26... Never argue with an idiot. He brings you down to his level, then beats you with experience... Remove SPAM-OFF to reply.
In article <[email hidden]>, "Jan Verschueren" <[email hidden]> writes: >Well Randy, > >From my experience, the problem is eeriely repeatable with this set of >servers. The infuriating bit is it doesn't effect everybody equally >(sometimes I can connect whenever and last night it took me 40 tries) and >some servers (Eldred's for example) don't seem to suffer at all. Huh? Sorry, I hadn't been paying attention until I saw my name. I don't know what the client/send stuff is set at - I'll have to check. Eldred -- Dale Earnhardt, Sr. R.I.P. 1951-2001 Homepage - http://www.umich.edu/~epickett F1 hcp. +24.63...F2 +151.26... Never argue with an idiot. He brings you down to his level, then beats you with experience... Remove SPAM-OFF to reply.
Ok Eldred, I'll bite.. What is this "Marvin the Martian voice" thingy? "EldredP" wrote: | <insert Marvin the Martian voice> | That made me *very* angry... | Eldred --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.256 / Virus Database: 129 - Release Date: 5/31/2001
Yet another post that makes me feel old... "Thom j." <[email hidden]> wrote in message news:RzdT6.33998$[email hidden]...
Quoted text (15 lines)> Ok Eldred, I'll bite.. What is this "Marvin the Martian voice" thingy? > > "EldredP" wrote: > | <insert Marvin the Martian voice> > | That made me *very* angry... > | Eldred > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.256 / Virus Database: 129 - Release Date: 5/31/2001 > > >
C'mon Thom, you've just got to know Marvin the Martian?! From the Bugs Bunny cartoons?? -"I am going to blow up the Earth." ?? Ring a bell yet? -Doesn't anybody on RAS watch cartoons? Jan. =--- "Pay attention when I'm talking to you boy!" -Foghorn Leghorn. Thom j. wrote... > Ok Eldred, I'll bite.. What is this "Marvin the Martian > voice" thingy?<snip>
"O" ok! Sorry. I'm a bit brain dead today {or any other day to be honest!} Eldred just thru me when he was so upset about getting his voice back..lol Anyway thanx for ringing my bell... <G> Cheers Thom_j. "Jan Verschueren" <[email hidden]> wrote in message news:[email hidden]... | C'mon Thom, you've just got to know Marvin the Martian?! From the BugsBunny | cartoons?? -"I am going to blow up the Earth." ?? | | Ring a bell yet? -Doesn't anybody on RAS watch cartoons? | | Jan. | =--- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.256 / Virus Database: 129 - Release Date: 5/31/2001
Jan Verschueren wrote: > C'mon Thom, you've just got to know Marvin the Martian?! From the Bugs Bunny > cartoons?? -"I am going to blow up the Earth." ?? > > Ring a bell yet? -Doesn't anybody on RAS watch cartoons? You bet ... I even have a Marvin the Martian headcover for my driver (we're talking golf clubs here). My cable TV company just added the Cartoon Network, which my kids are watching constantly. I saw Marvin just yesterday, in fact. Dave Ewing -- ***************************************************** David A. Ewing Xilinx Boulder [email hidden] *****************************************************
DB 06 Jun 2001 18:45 UTC↳ reply to David Ewing#180377
C'mon Jan, Most of us have better things to do than get lost in some make believe cartoon world, Now excuse me while I go run a few laps at Monza. DaveB, :) "David Ewing" <[email hidden]> wrote in message news:[email hidden]... > Jan Verschueren wrote: > > > C'mon Thom, you've just got to know Marvin the Martian?! From the BugsBunny > > cartoons?? -"I am going to blow up the Earth." ?? > > > > Ring a bell yet? -Doesn't anybody on RAS watch cartoons? > > You bet ... I even have a Marvin the Martian headcover for my driver(we're > talking golf clubs here). My cable TV company just added the CartoonNetwork, > which my kids are watching constantly. I saw Marvin just yesterday, infact.
Quoted text (12 lines)> > Dave Ewing > > -- > ***************************************************** > David A. Ewing > Xilinx Boulder [email hidden] > ***************************************************** > > > >
Hey Devid E, There is a great idea for my players pic! Me or a cartoon of me with a "Marvin the Martian" helmet! I could eveb take a pic of the tv from the "Cartoon Network" & doctor it up as my own personal player pic.. Thanx for the idea!! Thom_j. "David Ewing" wrote: | You bet ... I even have a Marvin the Martian headcover for my driver(we're | talking golf clubs here). My cable TV company just added the CartoonNetwork, | which my kids are watching constantly. I saw Marvin just yesterday, infact. | Dave Ewing --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.259 / Virus Database: 130 - Release Date: 6/5/2001
In article <RzdT6.33998$[email hidden]>, "Thom j." <[email hidden]> writes: >Ok Eldred, I'll bite.. What is this "Marvin the Martian voice" thingy? > >"EldredP" wrote: >| <insert Marvin the Martian voice> >| That made me *very* angry... >| Eldred Fer cryin' out LOUD, Thom! How old ARE you?<g> Warner Bros. cartoons, man - CLASSICS! Cartoon Network had a Bugs Bunny marathon this past weekend. I probably recorded 90% of it.... Eldred -- Dale Earnhardt, Sr. R.I.P. 1951-2001 Homepage - http://www.umich.edu/~epickett F1 hcp. +24.63...F2 +151.26... Never argue with an idiot. He brings you down to his level, then beats you with experience... Remove SPAM-OFF to reply.

Sponsors

Affiliate Links

Sim Gaming Expo MOZA Racing Sim-Lab Fanatec TrakRacer Asetek Internet Privacy From NordVPN Dreamhost Capital One Credit Card Application Fanatical CDKeys Amazon Amazon UK Project Motor Racing iRacing Get your racing gloves, boots and more from Demon Tweeks. Enlist at Roberts Space Industries, developers of Star Citizen and Squadron 42


Back from the ashes since July, 2019. First created in 2001 with the merger of Legends Central (founded 1999) and simracing.dk.

A site by a sort of sim racer, for sim racers, about racing sims. News and information on both modern and historic sim racing software titles.

All products and licenses property of their respective owners.


Facebook Threads Bluesky Twitter Mastodon Instagram YouTube Tiktok Twitch Reddit Google News Apple News Subscribe via WordPress Flipboard eBay

Race Sim Central © 1999-2026 | Some links pay RSC a commission. Advertising does not equal endorsement.Cookie Policy