http://www.ietf.org/rfc/rfc1063.txt

Parameterhandling im chaotischen, gesetzlosen Immernet ist so alt wie das immernet selbst. Habe sicher ne 1000mal überholte RFC erwischt, zeigt aber schön dass damals wie heute das MTU-Chaos Probleme bereitet.

WENN man bei BIS im Client die MTU size on the fly ändern könnte (ist das im SOCKET realisiert oder im OS/Treiber?) DANN könnte BIS ähnlich wie bei einer Regelschleife einer Fehlerkorrektur bei Fragmentierung die MTU solange runtersetzen bis es nicht mehr auftritt.
Damit würde den Nutzern das selber rumfummeln erspart bleiben.

Edit: knapp daneben, scheint nur die 1191 drüber zu sein, eine Wischi-Waschi-RFC die viel offen lässt. Der win7 tcpip stack kann angeblich MTU discovery, kann es sein dass BIS dös net in ihrem Socket implementiert hat?

EditEdit: Bringt mich zu IPv6 wo es solche Probleme gar nicht mehr geben kann........weiss nur nicht wo BIS's SOCKET-socket am OS Stack ansetzt.........und welche Funktionen von dort genutzt werden. Wenn es voll transparent ist kein Problem, hoffe nur dass wir nicht TTs bekommen wie "habe IPv6 ISP und kann nimmer ArmA zoggen...."

Bin ich der einzige der nüscht versteht wat der da schreibt?

Klingt aber für mich als ob du Ahnung von dem Ganzen Sytem hast Inno? Frage mich dann warum nach Jahren mit ArmA nüscht an Addons von dir kommt was dem irgendwie mal abhilfe schafft? Bzw warum du nicht bei BIS Anheuerst wenn du anscheinend die Lösung für alles hast?

Aber um zum Thema zu kommen:
Sieht mir stark danach aus als ob wir eine 1.60er unterm Weihnachtsbaum zu liegen haben.

:zahn:Dito

da fällt mir nur leintuch dazu ein :D

hat i&c nicht gesagt das er anleitungen schreibt, von den programmen die seine "bitschubser" "schubsen" ??

wenn anleitungen so aussehen, dann will ich kein user sein :lol:

Mal wieder geil, das Inno/Hämmer-Gebäshe hier zu lesen :lol:

inno, programmier doch mal was für die engine. Wenn ich wüßte, was elementar schiefläuft und hätte das knowhow, passend dazu was zu basteln, ich würd keine Sekunde zögern.

Ich weiß auch nicht wie man ein Auto baut, aber wie es fahren muss.

Werdet ihr vom Autoverkäufer/Werkstattbesitzer auch so dämlich angebläht wenn ihr aus versehen von Teilaspekten Ahnung habt und auf einer anderen Meinung besteht? Sagt der Autoverkäufer auch ignorant "sie idiot, bauen sie erst mal selbst ein Auto und kommen dann wieder..."


Ich bin kein coder. Und vom IP Stack, vor allem L1 und L2, hab ich nur rudimentäre Ahnung. Aber die RFCs sind doch leicht zu verstehen und da steht doch (fast) alles drin. Also wo ist das Problem? wollen wir jetzt über die faktischen und möglichen Verbesserungen des "Netcodes" reden oder darüber was hammergut meint was ich darüber wissen kann/darf?

Und wenn man Spezifikationen versteht, dann heisst es noch lange nicht, dass man sie programmieren kann. Was ich aber damit könnte, wäre mit z.B. Wireshark tracen wie genau sich alles auf dem Interface/Referenzpunkt Lan-Adapter verhält und in gewissen Grenzen auch beurteilen.

Du liest nicht sorgfältig. Ich schreibe ganz oder teilweise Anforderungskataloge/Weißbücher/Spezifikationen für Programme/Programmteile/Module/Funktionen.

Kann auch jeder von euch weil man dazu eigentlich nur Logik braucht.
Genau so, wie ein Programmierer sich in den Möglichkeiten der gewählten Programmiersprache(n) bewegt, bewege ich mich in dem Rahmen der gewählten/gesetzten Protokollspezifikationen.


Ich hatte ja mal gefragt ob einer weiß wo den die horizontale Schnittstelle zwischen dem, was der Treiber der LAN-Karte+OS bereitstellt und dem ominösen "Socket" den BIS reingeschraubt hat ist. Dann könnte man erst mal beurteilen für welche Fehler/Wünsche man BIS oder besser Microsoft anplärrt.

Wenn BIS ein klein wenig mehr erklären würde könnte man auch viel bessere Reports schreiben oder auch viel besser Beta-testen.

Wenn BIS zB den Inhalt/Sinn der datagramme oberhalb TCP/IP soweit offenlegen würden wie es möglich ist ohne der Konkurrenz Vorteile zu verschaffen, dann könnte ich jemanden finden der eine idl für Wireshark schreibt (nein, hammergut, ich kann das nicht, sondern nur wie die idl den Verkehr interpretieren soll beschreiben) oder BIS könnte selbst eine idl für wireshark bereitstellen wenn sie nicht sogar selbst schon so etwas haben.

Unsereiner könnte dann fertig analysierte traces von Server-NIC und einigen client-NICs bereitstellen und den Bezug zu dem was da ingame gerade abging. Im Idealfall wüssten wir/BIS exakt welche Aktionen Ingame welchen Traffic am Interface ausgelöst hat.

Hört sich wie Voodoo an? Gut, dann verdiene ich mein Brot eben mit Voodoo, hab ich ja Glück dass es noch Firmen gibt die mir immer und immer wieder Geld für meine völlige Inkompetenz zahlen.

So, und jetzt geht der Thread wieder in Richtung Beta Patches, sonst werde ich böse!

Daher, neuer Beta Patch verfügbar, 87636

Changelog:
Xeno

Ok, dann mal die Suchmatrix wenn man wirklich mal wissen will was überhaupt gefixt wurde in betas/RCs und full patches:


ROFL

Und eine weiterer Post 1.60 Patch Beta, 87646

Changelog
+ Crash Fixes

Xeno

Der Pätsch für den Pätsch - Ein BIS Trademark ^^

Ein böhmischer Quilt.

Macht sich toll als Familienerbstück und hält warm :D

Da werden bis 1.61 noch einige kommen da für 1.61 alle offenen CIT Tickets angeschaut werden sollen... (was das jetzt genau heißt, ka).

Xeno

Und danach ist die Annahmestelle des CIT bis A3 (!s-line^^) geschlossen? ;)

Wer weiß was bis A3 noch alles kommt, äh, passiert, äh, was auch immer ;)

Xeno

Ehm ich denke im Sommer 2012 gibt's die Ankündigung der Verschiebung auf 2013 :zahn:

Jetzt gibt es wohl Hot-Fixe und Beta-Pätsche gleichzeitig???????

Solange es noch keinen -hotfix Paramater für die .exe gibt ist das nicht offiziell :confused:

Sagt mal, wie schnell werden die Beta-Patches beim Sixupdater eingepflegt?

Kann man das irgendwie manuell machen?

Sorry, arbeite mich gerade erst in den SU ein.

Die Hot Fixes sind primär für Server gedacht.

Nicht so schnell wie sie erscheinen da das vom ACRE Update abhängt.

Neuer, 87658

Changelog:
Xeno