TIM:
Δημοσιεύθηκε: Τρι 18 Ιαν, 2005 2:17 am Θέμα δημοσίευσης: Multiplayer Enhancements in BMS
--------------------------------------------------------------------------------
Παράθεση:
13 MULTIPLAYER ENHANCEMENTS
BMS contains some MP tweaking that should extend multplayer experience. There were found
some leftovers from previous debug and testing which ment that packets were dropped instead
of being send to players. Also some tweeking with the packet size has been made.
This section explains these tweeks and how to enable/disable them.
13.1 TCP/IP MAXIMUM TRANSMISSION UNIT SIZE (MTU)
In all previous versions of Falcon 4, the TCP/IP MTU packet size was default set to 500 which
ment that packet sent between players never exceeded that size even if the messages was
larger. Since Windows 98 SE the use of bigger TCP/IP packets has been possible and therefore
we introduce the –MTU switch. With this you are able to control what size you will use for MTU.
For example. –MTU 1514 in the commandline for Falcon would triple the amount of data in each
packet and save packets send between players. (Initial testing only allowed 750 as a max value).
If you do not receive a commit button you will need to reduce the size.
Make some test to see what size that gives best multiplay between players and make sure all
players uses the same MTU size.
One new configuration variables has been added to the falconbms.cfg:
set g_bF4CommsMTU 1
One new commandline switch has been added:
-MTU XXX (where XXX is the maximum size of packet)
The MTU switch will only be active if the configuration variable g_bF4CommsMTU is equal 1.
Otherwise it defaults to 500 in MTU size.
13.2 DISABLE PACKETS LOSS
Some leftovers (forgotten) code that simulated drop of packets can now be disabled. This means
that all packets will be sent to players but it also increases the data transferred.
One new configuration variables has been added to the falconbms.cfg:
set g_bF4CommsKillPL 1
Απο το BMS 2 manual
Μπορει καποιος να μου εξηγησει ακριβως τι κανουν αυτες οι ρυθμισεις? Μπορουμε να επωφεληθουμε απο αυτες? Πρεπει να τις εχει και ο server και οι παικτες?
Ευχαριστω προκαταβολικα...
_________________
Multiplayer Enhancements in BMS
Συντονιστές: the_ripper, Διαχείριση
Multiplayer Enhancements in BMS
e-HAF Admin
Όλα αυτά κάνουν αυτά που λένε.....
Το όλο θέμα είναι ότι πρέπει στον Server να τρέχει για κάποιο καλό χρονικό διάστημα ένα πρόγραμμα που να μας αναφέρει όλες αυτές τις πληροφορίες - στατιστικά όπως το MTU και το max BW που είναι διακόπτες για το exe.
Δεν υπάρχει κάποιος χρυσός κανόνας.
Τρέχεις τα τεστ σου βλέπεις τα στατιστικά που παίζει το δίκτυο και βάζεις τις αντίστοιχες τιμές.
Ένα λινκ που βρήκα για το MTU είναι και αυτό
http://www.ncne.org/jumbogram/mtu_discovery.php
Για info
http://www.microsoft.com/resources/docu ... /58792.asp
επίσης από ένα καλό εργαλείο (xteq) αναφέρει τα εξής για το Auto detection του MTU:
Inside a network, there is always a "data window" called Maximum Transmisson Unit (MTU) that defines how many data somebody can sent before an acknowledge needs to be sent.
For example, in a default Ethernet network the MTU is 567 bytes. An example: a Client wants to sent some data to a server. The client first checks how big the current MTU is and splits the data (if needed) into chunks of 567 bytes. It then sends out the first chunk of 567 bytes and waits until the server send back a "OKAY, I received the 567 bytes correctly" message before the next chunk is sent.
567 bytes are good for most networks, but there might be cases where you need a bigger, or a smaller MTU. For example, if two server are connected with 1 GBit to each other, you can properly extend the MTU so they can sent more data in one step and speeding up the connection (less "OKAY, got that" messages). For this reason, Windows tries to automatically detect which MTU size it should be using.
Normally, there is absolutely no need to change this value but if you server is connected to the internet, some back hacks could trick Windows in such way that it thinks it should use a MTU of 1 byte. This means your server will send one byte of an HTML page and wait until the client says "OKAY, got that". Then it will send the next byte etc. This will of course result in a really bad performance of your server since it waits for OKAY messages most of the time.
If this automatic detection is turned off, a hacker can not trick the server.
Η ρύθμιση για το packet loss πιστεύω ότι είναι ξεκάθαρη απλά το ενεργοποιούμε.....για να μην χάνουμε πακέτα.
Άρα εφόσον συμφωνήσουμε θα πρέπει όλοι μας να κάνουμε αυτές τις ρυθμίσεις. δηλ.
να δηλώσουμε το
set g_bF4CommsMTU 1
στο cfg
όπως και το
set g_bF4CommsKillPL 1
επίσης στο cfg
μετά σύμφωνα με το BW και τα πακέτα του SERVER ρυθμίζουμε την τιμή του MTU και του BW στου διακόπτες του .exe αυτό θα το καθορίσει ο Admin του Server.
Ένας παράγοντας που επίσης επηρεάζει το όλο σύστημα (και καλό θα είναι να το δούμε αν έχουμε προβλήματα με lag) είναι και το TeamSpeak φυσικά.....
Ένα καλό Test θα ήταν να σηκωθεί (για test μονο, αρκεί να είμαστε όλοι μέσα) campaign κανα βαρύ όμως DeepStrike (που γίνετε της κακομοίρας από data) και να μπούμε μέσα όσοι περισσότεροι μπορούμε να δούμε τι λέει το πράμα έτσι ώστε να βρούμε την κορυφή του. Καλό θα ήταν να βάζαμε on το να μην καταστρεφόμαστε έτσι ώστε να είμαστε online όλοι συνέχεια.
Αυτά. Ρωτώντας πας στην πόλη...
Τα κολλήματα όπως Ramp start κ.λ.π. δεν μας ενδιαφέρουν γι'αυτό....την επικοινωνία θέλουμε να τεστάρουμε.
Arty out...
Το όλο θέμα είναι ότι πρέπει στον Server να τρέχει για κάποιο καλό χρονικό διάστημα ένα πρόγραμμα που να μας αναφέρει όλες αυτές τις πληροφορίες - στατιστικά όπως το MTU και το max BW που είναι διακόπτες για το exe.
Δεν υπάρχει κάποιος χρυσός κανόνας.
Τρέχεις τα τεστ σου βλέπεις τα στατιστικά που παίζει το δίκτυο και βάζεις τις αντίστοιχες τιμές.
Ένα λινκ που βρήκα για το MTU είναι και αυτό
http://www.ncne.org/jumbogram/mtu_discovery.php
Για info
http://www.microsoft.com/resources/docu ... /58792.asp
επίσης από ένα καλό εργαλείο (xteq) αναφέρει τα εξής για το Auto detection του MTU:
Inside a network, there is always a "data window" called Maximum Transmisson Unit (MTU) that defines how many data somebody can sent before an acknowledge needs to be sent.
For example, in a default Ethernet network the MTU is 567 bytes. An example: a Client wants to sent some data to a server. The client first checks how big the current MTU is and splits the data (if needed) into chunks of 567 bytes. It then sends out the first chunk of 567 bytes and waits until the server send back a "OKAY, I received the 567 bytes correctly" message before the next chunk is sent.
567 bytes are good for most networks, but there might be cases where you need a bigger, or a smaller MTU. For example, if two server are connected with 1 GBit to each other, you can properly extend the MTU so they can sent more data in one step and speeding up the connection (less "OKAY, got that" messages). For this reason, Windows tries to automatically detect which MTU size it should be using.
Normally, there is absolutely no need to change this value but if you server is connected to the internet, some back hacks could trick Windows in such way that it thinks it should use a MTU of 1 byte. This means your server will send one byte of an HTML page and wait until the client says "OKAY, got that". Then it will send the next byte etc. This will of course result in a really bad performance of your server since it waits for OKAY messages most of the time.
If this automatic detection is turned off, a hacker can not trick the server.
Η ρύθμιση για το packet loss πιστεύω ότι είναι ξεκάθαρη απλά το ενεργοποιούμε.....για να μην χάνουμε πακέτα.
Άρα εφόσον συμφωνήσουμε θα πρέπει όλοι μας να κάνουμε αυτές τις ρυθμίσεις. δηλ.
να δηλώσουμε το
set g_bF4CommsMTU 1
στο cfg
όπως και το
set g_bF4CommsKillPL 1
επίσης στο cfg
μετά σύμφωνα με το BW και τα πακέτα του SERVER ρυθμίζουμε την τιμή του MTU και του BW στου διακόπτες του .exe αυτό θα το καθορίσει ο Admin του Server.
Ένας παράγοντας που επίσης επηρεάζει το όλο σύστημα (και καλό θα είναι να το δούμε αν έχουμε προβλήματα με lag) είναι και το TeamSpeak φυσικά.....
Ένα καλό Test θα ήταν να σηκωθεί (για test μονο, αρκεί να είμαστε όλοι μέσα) campaign κανα βαρύ όμως DeepStrike (που γίνετε της κακομοίρας από data) και να μπούμε μέσα όσοι περισσότεροι μπορούμε να δούμε τι λέει το πράμα έτσι ώστε να βρούμε την κορυφή του. Καλό θα ήταν να βάζαμε on το να μην καταστρεφόμαστε έτσι ώστε να είμαστε online όλοι συνέχεια.
Αυτά. Ρωτώντας πας στην πόλη...
Τα κολλήματα όπως Ramp start κ.λ.π. δεν μας ενδιαφέρουν γι'αυτό....την επικοινωνία θέλουμε να τεστάρουμε.
Arty out...
Arty out...
ΟΚ ευχαριστω για τις πληροφοριες Arty
Θα χρειαστω εθελοντες για να τα δοκιμασουμε ολα αυτα.
Αυτο σημαινει ατομα με σχετικη εμπειρια στο Falcon και ετοιμα setup σε CobraOne οπως αναφερεται σε αλλο post μου. Δειτε εδω...
http://www.e-haf.org/forum/viewtopic.php?p=14115#14115
Σημερα ειναι εκπαιδευτικη ημερα οποτε μετα την εκπαιδευση οσοι επιθυμουν να το δοκιμασουμε ας προσελθουν.
8)
Θα χρειαστω εθελοντες για να τα δοκιμασουμε ολα αυτα.
Αυτο σημαινει ατομα με σχετικη εμπειρια στο Falcon και ετοιμα setup σε CobraOne οπως αναφερεται σε αλλο post μου. Δειτε εδω...
http://www.e-haf.org/forum/viewtopic.php?p=14115#14115
Σημερα ειναι εκπαιδευτικη ημερα οποτε μετα την εκπαιδευση οσοι επιθυμουν να το δοκιμασουμε ας προσελθουν.
8)
Το 2ο ειναι ηδη δηλωμενο απο default και στο FF3 αλλα και στο C1 setup.Arty έγραψε:Άρα εφόσον συμφωνήσουμε θα πρέπει όλοι μας να κάνουμε αυτές τις ρυθμίσεις. δηλ.
να δηλώσουμε το
set g_bF4CommsMTU 1
στο cfg
όπως και το
set g_bF4CommsKillPL 1
επίσης στο cfg
Αρα απο αυτο ειμαστε ΟΚ
Τωρα για το πρωτο θελει ελεγχο. Και αυτο ακριβως σκοπευεω να κανω δοκιμαζοντας το βραδυ την τιμη MTU 750. Απο οτι καταλαβα μονο καλο μπορει να κανει και οχι κακο. Θα δειξει...
8)