Not receiving updates switching to tcp?

[scotty12]

what happened.  Everything seems fine then
I got this message when logged on today
Help!!!!

[Minotaur]

I have gotten it several times, my net connection is really slow when it happens.

Mino

[scotty12]

I corrected my problem
I went to my dial up connection and put the dns entries into my server types
tcp-ip settings and clicked on specify name server address then entered my primary and secondary dns numbers.
If you dodn't have them call your internet company

[Yentl]

I recieved the same message today also. I have a dsl connex and have had nothing but green beacons until today.  I dont believe its the new version because it was fine yesterday with .38  Did you change something?

[Yentl]

I logged onto WBs and I am having the same problem so its not Aces High or your server in my case.  I am in California I ran a tracert but couldnt figure out how to copy it onto this message board.

[Azrael]

Just FYI I get this message every time I log on - sitting behind a firewall.

Az

------------------
Azrael
XO 487th BG (Heavy)
'The Gentlemen from Hell'

[Yentl]

Seems unrelated but make sure that your joystick has poll with interrupts enabled
I did this and my connex went green again.  I believe that I saw this on the message board somewhere Hitechs suggestion. 8)

[TT]

What is the difference between a TCP/IP and a modem connection.

[Ozymandias_KoK]

TCP/IP is just a protocol running on yer modem connection.  Analogy: yer modem connection is when you call somebody on the phone, TCP/IP is the language you speak in to the person on the other side.

------------------
TKoKFKA-OZDS-

[Dancer]

If you have an internet connection you basically
have the choice between two types of connection:
TCP or UDP.

I guess, AH tries to use UDP and if that
doesn't work, it switches to TCP.

The difference is that UDP doesn't control
if a data package is really received at
the target while TCP does.

I think that NAT is only possible with TCP
so everyone behind a firewall/proxy which
uses NAT (like me, eg.) get's the message
every time.

Dancer out.

PS:
IP = Internet Protocol
TCP = Transport Control Protocol
UDP = User Datagram Protocol
ICMP = Internet Control Message Protocol
NAT = Network Address Translation

[Lephturn]

Dancer hit the nail on the head.  

I want to add that UDP is generally faster than TCP, and that's why it tries to use UDP first.  If your connection goes south, it will try switching to TCP and see if that works, but generally if you are on a regular connect and see "Switching to TCP", you will likely see a "Host Connection lost" message very soon after.


------------------
Lephturn
The Flying Pigs

[Dancer]

Lep is right.

UDP is faster since it's like "streaming" or
"broadcast". The server "pumps out" the data,
if the client doesnt get the up-dates, well,
"switch to TCP  

UDP doesn't have the "hand-shake" control that
TCP has.

It's like you are standing on your soap-box,
shouting at the crowd - if some can't hear
you (and you notice), you'll address them
directly ("Hay, Sir/Lady, did you hear what
I'm dweebing about???"   )

So while UDP is faster, it comes with the
expense of un-reliability.

Dancer out.

[Duck]

Actually for real time positioning information UDP is definately the way to go.

While UDP traffic is just letters dropped into the sea of the internet, and no guarentees that letters will arrive in the order you sent them, or even arrive at all.

TCP is great, because it takes care off all this crud.  It guarentees that your packets will arrive, and in the order that you sent them.  This comes at great cost for real time protocols when a packet is lost.

In TCP a packet begins it's life on the net just like a UDP packet.  It's dropped onto the network addressed to it's destination.  However the sender does not forget about the packet yet.  It keeps track of the data that has already been sent until a packet arrives back from the destination saying that that sequence of data has been successfully receieved.  But if such acknowledgement doesnt arrive in a certain amount of time (usually a second or two  depending on the average transit time for the packets)  The source will send the packet again.  Now while the destination side has been waiting for this lost packet to arrive, it has been accumulating the subsequent packets.  It cannot deliver them to the application because it must deliver the data in the order that it was sent.  So in effect it is holding on to all this recent positional updates while while waiting for a lost packet to be resent and arrive.  In addition the contents of that packet are probably irrelevent by the time that it arrives and application is flooded with all the backlogged packets.

So UDP is the way to go for positional updates, but TCP still reigns supreme for non-realtime data such as radio traffic, and damage assessment.

As far as proxying UDP traffic through the firewall, it is entirely possible to NAT udp traffic, as long it is a well behaved (initiated from behind the NAT device using a random port number to a fixed port on the destination) protocol.  However most all
firewalls will need to be specially configured to open up those UDP ports because they will be closed by default.

Regards,
Michael Carney aka duck