Resynchronisation eines asynchronen Sockets ^^

[Meflin]

Moin,

nachdem mein asynchroner Socket jetzt einwandfrie läuft, stehe ich vor dem Problem, dass manches doch besser synchron ablaufen würde. Konkret gibt es zwei Szenarien, die immer parallel ablaufen:

1) Es treffen Nachrichten unvorhersehbar ein, die abgearbeitet werden sollen (der bisher asynchrone Part)
1a) Es werden Nachrichten asynchron gesendet, Ergebnis ist erstmal irrelevant

2) Es wird eine Nachricht gesendet, aber der Methodenaufurf soll blockieren, bis eine entsprechende Antwort empfangen wurde, und diese Antwort soll zurückgegeben werden. Nicht auszuschließen ist dabei natürlich, dass vor der gewünschten Antwort weitere der o.g. nicht vorhersehbaren Nachrichten eintreffen.

Zu diesem Zweck hatte ich mir folgendes gedacht:

Code:

public object SyncSend(string command, object payload, string syncCommand = null)
{
    synchronizedSend.Reset();
    targetCommand = syncCommand == null ? command : syncCommand; 
    Send(command, payload);
    synchronizedSend.WaitOne();
    return synchronizedObjects.Dequeue();
}

Wobei Send das bisher verwendete asynchrone Senden ist und das asynchrone ReceiveCallback synchronizedSend bei Empfang eines adäquaten Objekts signalisiert.

Problem an der Sache: dieses ManualResetEvent blockiert allem Anschein nach auch dieses asynchrone Receive, was quasi in einer endlosschleife läuft (ReceiveCallback ruft wieder BeginReceive auf).

Und ich sehe absolut keinen Grund, wieso dem so sein sollte. Das hieße ja, dass beide Methoden im selben Thread liefen, und das ergibt irgendwie keinen Sinn.

Wer kann mir helfen?

[Meflin]

:cyclops:

[shmia]

Erwartest du für jede Message eine Antwort oder Quittierung?
Oder sind deine Messages im Protokoll irgendwie durchnummeriert?

Edit:
Ok, du hast ja geschrieben dass unvorhersehbare Nachrichten eintreffen können.
Das bedeutet, dass im Protokoll auf OSI-Ebene 7 die Messages irgendwie gekennzeichnet werden müssen.
Das Einfachste wäre eine fortlaufende ID zu vergeben.

[Meflin]

Hm, vielleicht sollte ich doch meine Fragepostings etwas kürzer&pregnanter fassen :stupid:

Ich habe kein Netzwerkproblem - es handelt sich vielmehr um ein generelles .Net-Multithreading-Problem, zumindest gehe ich davon im Moment aus. Ein ManualResetEvent blockiert allem Anschein nach einen asynchronen Socket-Callback, und das dürfte meines Verständnises nach einfach nicht passieren.

[Meflin]

Push ^^

(Ich würde ja auch gerne den Titel ändern, aber irgendwie sind jegliche Bearbeitungsfunktionen verschwunden?!?! Ach ja, da war ja mal sowas mit 24h :roll:)

[mkinzler]

Zitat:

(Ich würde ja auch gerne den Titel ändern, aber irgendwie sind jegliche Bearbeitungsfunktionen verschwunden?!?!

Wenn du uns den gewünschten Titel nennst, könnte einer vom Team das für dich erledigen

[Khabarakh]

Was heißt das nun genau? Es kommt zu einem Deadlock, bevor der BeginReceive-Callback überhaupt aufgerufen wird? Das dürfte wirklich nicht passieren, da die in einem neuen Threadpool-Thread ausgeführt werden. Sollte es trotzdem einer sein - nicht verzagen, SOS fragen :) http://blogs.microsoft.co.il/blogs/s...ng-demo-4.aspx

Warum du den Programmteil aber unbedingt synchron ausführen lassen musst und nicht mit einer Art von Continuation arbeiten kannst (Rx würde sich hier wahrscheinlich anbieten :) ), habe ich noch nicht verstanden.

[Meflin]

Zitat:

Zitat von Khabarakh (Beitrag 1051631)

Was heißt das nun genau? Es kommt zu einem Deadlock, bevor der BeginReceive-Callback überhaupt aufgerufen wird? Das dürfte wirklich nicht passieren, da die in einem neuen Threadpool-Thread ausgeführt werden. Sollte es trotzdem einer sein - nicht verzagen, SOS fragen :) http://blogs.microsoft.co.il/blogs/s...ng-demo-4.aspx

Ja, ganz danach sieht es aus. Ich sehe per Wireshark das passende Antwortpaket eintreffen, aber der ReceiveCallback wird einfach nicht mehr ausgeführt. Den DeadlockDetector konnte ich leider spontan nicht kompilieren - na mal gucken :stupid:

Zitat:

Warum du den Programmteil aber unbedingt synchron ausführen lassen musst und nicht mit einer Art von Continuation arbeiten kannst (Rx würde sich hier wahrscheinlich anbieten :) ), habe ich noch nicht verstanden.

Nunja. Ich befinde mich gerade in einem asynchronen Callback und muss dort u.U. weitere Detaildaten abfragen. Diese Detaildaten muss ich unbedingt dem derzeitigen Datensatz zuordnen. Die Antwort enthält aber nichts, was diese Zuordnung ermöglichen würde. Deshalb ging ich bisher davon aus, dass die einfachste Lösung eben ein blockierender Funktionscall wäre, der die passende Antwort zurückgibt - der aber eben auf der asynchronen Basis arbeiten muss. Natürlich könnte ich das auch einfach asynchron abfragen - nur die Zuordnung zum richtigen Datensatz erscheint mir dann im Moment doch als einziger PITA ;)

[Khabarakh]

Zitat:

Zitat von Meflin (Beitrag 1051633)

Natürlich könnte ich das auch einfach asynchron abfragen - nur die Zuordnung zum richtigen Datensatz erscheint mir dann im Moment doch als einziger PITA ;)

Wofür gibt's Closures :D ? Code, der Daten in einem Kontext auswerten soll

Code:

var a = Foo();
var b = Receive();
a.Process(b);

wir mit einer (asynchronen) Continuation in etwa zu

Code:

var a = Foo();
BeginReceive(b => a.Process(b));

Damit ist die Transformation doch wirklich beherrschbar ;) . Und alle state-Parameter sind dadurch auch überflüssig geworden.

[Meflin]

Öh ja. Muss ich mir erstmal genauer angucken - hab ich noch keine Ahnung davon :stupid: