i-Telex Extension-Nummer (Durchwahl)

[WolfgangH]

Hallo Fred,

der Log von heute 18:26 war der Mitschnitt meiner Nachricht an Detlef (211231) auf vermutlich sein i-Telex. Ich hoffe, ich kann damit die Verwunderung etwas mildern. Inhaltlich kann ich leider nichts dazu beitragen. Softwaremäßig bin ich blind.

[detlef]

Es geht hier bei der Analyse erstmal gar nicht um meine Dienste, deswegen habe ich die komplett aussen vorgelassen.

Ich habe das Verhalten der Version 915 mit der 966 verglichen (nur darum ging es). Als Gegenstation habe ich ein i-Telex gewählt (die 211231), weil ich nur dort alle ankommenden Pakete sehe. Meine Dienste unter Windows sind zu langsam dafür.

Das Verhalten der 915 und der 966 ist reproduzierbar.

Es wäre halt für mich hilfreich gewesen, zu erfahren, welches das (nach der Programmierung) erwartete Verhalten ist. Das mit oder das ohne Delay.

[FredSonnenrein]

Ich werde mal nachsehen, ob die Verzögerung bei den neueren Versionen „verlässlich“ ist oder nicht.

Was ich mich frage ist:

Wo bleiben die Daten des „verlorenen“ ersten Pakets? Aus der Sicht des i-Telex ist es ka erfolgreich übermittelt, also hat Windows ein TCP ACK gesendet.

[detlef]

Wo bleiben die Daten des „verlorenen“ ersten Pakets? Aus der Sicht des i-Telex ist es ka erfolgreich übermittelt, also hat Windows ein TCP ACK gesendet.

Das ist eine gute Frage. Das verstehe ich im Moment auch noch nicht so richtig. Aber der Hinweis ist gut. Die Daten müssen ja irgendwo gepuffer werden.

Ich verwende eigentlich ein Standard-Pattern und das schon seit vielen Jahren. Aber anscheinend ist es bisher nie vorgekommen, dass direkt in den ersten Millisekunden nach dem AcceptTcpClient() schon Zeichen gesendet werden. Bis das BeginReceive() aktiviert ist, das auf eingehende Zeichen horcht, dauert es eben einen Moment. Vorher muss ich noch einen Task erzeugen.
Das ist mal wieder kaum zu glauben, dass so ein Standard-Pattern so kläglich versagt.

Ich schaue jetzt mal, wie ich an den Socket-Puffer rankomme.

[FredSonnenrein]

Ich habe jetzt mal auf die Schnelle die Quellcodes der Versionen 915 und 966 verglichen.
Da ist keine Änderung vorhanden, die das von dir beobachtete Verhalten begründet.
Meine Vermutung ist daher, dass ein anderer Unterschied besteht. Hattest du auf dem selben i-Telex beide unterschiedlichen Versionen installiert?
Oder sind es unterschiedliche Anlagen mit ggf. unterschiedlichen Konfigurationen?
Ratlose Grüße,
Fred

[detlef]

Nach den mehrfachen Anrufen von Wolfgang mit der 915 sieht es tatsächlich so aus, dass diese Version immer ohne Delay sofort lossendet, während ich bei meinen Anrufen mit der 966 immer ein Delay sehe. Wenn es im Programmcode keinen Unterschied gibt, dass liegt der Unterschied wohl in der Konfiguration.

Aber da der Workaround in meinem Service anscheinend funktioniert, hat sich das ja erledigt. Das ist aber wieder typisch Microsoft. Die bauen tolle Klassen zur Abstraktion und Vereinfachung, und wenn es drauf ankommt, dann muss man doch wieder zu Fuss alles mögliche drumrum programmieren.

[WolfgangH]

Hallo Detlef,

ich könnte ja jetzt bei einem System einmal die 966er Version draufspielen und Dich dann nochmals anrufen. Das Update kann ja ohnehin nicht schaden.

[detlef]

ich könnte ja jetzt bei einem System einmal die 966er Version draufspielen und Dich dann nochmals anrufen. Das Update kann ja ohnehin nicht schaden.

Nach dem Update ist vielleicht auch die Einstellung weg, die den Unterschied macht. Aber egal. Ich würde auf jeden Fall mal updaten.
Diesem Problem müssen wir, wie gesagt, nicht weiter nachgehen. Das i-Telex verhält sich ja korrekt. Ist eher das Problem von Windows, dass das so lahm ist.

[WolfgangH]

Ich habe jetzt die 966er Version aufgespielt, ohne irgendwelche Änderungen in der Konfiguration zu machen. Danach habe ich Dich wieder 3x auf der 211231 angewählt. Hat wieder bestens funktioniert. Ist da jetzt ein Unterschied erkennbar?