I cant host!

[Zapple]

Mac OSX
Armagetron v. 2.6
Wi-Fi

I turned firewall on and alowed port 4534 to alow me to host games, but when I do ti doesnt show up on the list!

See pic, instruct me if possible, Ill keep posting screenshots for your steps.

[Tank Program]

Sure you opened port 4534 UDP?

[Lucifer]

Hey zapple, you might want to consider looking over that screenshot and blurring the name. Especially if you're really 12 like everyone says you are.

[iceman]

ah so that email i got was really you then zapple
*grins evily whilst thinking of things to do with his ip and all those ports listed* (joking)

yeah make sure you enabled UDP port 4534 and not TCP/IP port

[Zapple]

Whats UDP?

[Lucifer]

Whats UDP?

Universal Datagram Protocol, if I recall correctly. It doesn't have error checking, like TCP, and there isn't any way to deliver packets out of order. It's preferred for gaming because it's low latency. TCP requires an acknowledgement of some sort for every packet sent, and a packet will be resent if there's either no acknowledgement or if it's the wrong acknowledgement.

VOIP uses UDP too, for the same reasons.

[philippeqc]

Whats UDP?

Universal Datagram Protocol, if I recall correctly. It doesn't have error checking, like TCP, and there isn't any way to deliver packets out of order. It's preferred for gaming because it's low latency. TCP requires an acknowledgement of some sort for every packet sent, and a packet will be resent if there's either no acknowledgement or if it's the wrong acknowledgement.

VOIP uses UDP too, for the same reasons.

Mostly your correct[as much as a 4 line explication can allow you, much more than what is required for Zapple], but there was one big mistake in your explication (but its not important for Zapple's firewall)

About the out of order, UDP can deliver packets out of order and most likely, will.

To give an explication that the less computer oriented ppl could understand. In UDP, you just send the packets on the network. What ever your computer receive, it passes it to your application, IN THE ORDER that it received it. What ever you dont receive, you dont even get to know that someone attempted to send it to you.

Because of the nature of networks, 2 packets can take different path to reach the destination. It is then possible for a packet sent at a later time to arrive before one sent before itself.

So it someone where to send the numbers 1 to 5 on UDP with one number per packet, the application on the other side might receive 1 4 3 5 and never receive 2, and never know that it was supposed to receive 2, or that the numbers where supposed to be in order.

-ph

[iceman]

now you've confused the poor lad

[2b|!2b?]

Well almost correct, but not fully.
With TCP packets, the protocol takes care of packet orders, missed packets, duplicates, etc.
With UDP, the application needs to take care of all of that. So when UDP packets arrive out of order, the application needs to re-order them. If a packet is missing or there is a checksum or data error, *and* the application cares about it, then it re-orders the packet by sending a request to the sending application (which, of course, has been programmed to take care of retransmitting missed UDP packets.)
So applications who cares about what they receive usually use TCP because then they don't have to manage the network layer. However, some very talented hackers have used UDP and even ICMP to emulate telnet-like programs and they programmed them with packet management. Very sneaky but very cool.

[philippeqc]

Well almost correct, but not fully.

Yes I know, it was just a short explication so non technical ppl could understand the basis of the problem.

But you gave a good explication too.

Now that everybody's mind is confused by all our details, I'll try to add an easy example.

In a game like armagetron, it is POSSIBLE to live with all this mess without much problems.

Lets say a player makes a right and after a short time a left turn. The application sends 2 messages to the server, each holding information like: position when the cycle turned, time into the game when the turn occured, new direction and speed and probably some other info. We will designate the 2 packets A and B.

Now assume that for some reason, B actually arrive on the server before A.

By itself the packet seems to be false. The position doesnt match where the cycle should be, and the turn info say that it "turned" to the exact direction that it was heading to in the first place. But by knowing the game mechanism, and that only one turn is missing, the server can still reconstruct the path that the cycle took to end up at the received position.

If and when A arrives on the server, the server may correct its assumptions, or simply discard it.

So you see in this example that order of delivery is not always required.

-ph

If your interested in the subject, I really suggest that you read about it. This example was quite simple. The situation can get very interesting when multiple packets are missed or delivered out of order.

Edit: I dont know how armagetron deals with this, I havent read the code. This was only ONE naive way to implement it.

[Lucifer]

Philipe, you willing to offer that as an explication (your word) for so-called lag sliding? Seems like something you might want to put under the lag topic elsewhere. Whether it's actually accurate or not on how AA actually deals with it, it's good enough for users to conceptualize lag sliding and understand what's happening when it happens.

[Zapple]

...
...
...

How do I make it able to host games?
lol

[/dev/null]

HMMMMMMMMM


Ok, i got a few ideas on this. One, I wonder if moving armagetron to use tcp would help with the lag issues. Also, anyone happen to know why armagetron doesnt come close to using the full bandwidth potential of a connection, My tron rarely breaks 3 or 4 kilobytes a second with 7 or 8 people on my server. If someone does happen to know how to force tron to use the full bandwidth please let me know, cuz that would likely considerably help.

[2b|!2b?]

I may not have understood your question but I'm going to answer it regardless! You cannot make an application use the entire network bandwidth of the connection it is hooked to. If Tron only uses a few kbps to handle a game as a server with a few bikes then that is all it needs. That the computer is connected to a 100mbps pipe means nothing. You can't make armagetron use the 100mbps if it does not need it.
Of course in real life what is important is the weakest (usually the smallest but not always) network link. If there is a congestion uplink to the server then tron will be restricted regardless of the server network capacity.
Hell! we all have felt that kind of impact when someone plays *and* is also downloading music or porn at the same time. They become an impact as they have restricted their client ability to communicate with the server.

[ishAdmin]

I think lag is unavoidable. The fact is, we are talking about a game where the landscape changes vastly based on fractions of seconds. There's a big difference in what happens with even a 50 ms delay. The information you get on what another player did is at least that old, even with the best of connections. I don't doubt that lag could be improved, but it can't be eliminated. I also bet a major rewrite will be needed to improve it. If only for the fact everyone around is having to figure this program out.