WCF-und streaming-Anfragen und-Antworten

Ist es richtig, dass in WCF, ich kann nicht von einem service schreiben zu einem Bach, der vom client empfangen wurden?

Streaming wird unterstützt von der WCF für Anforderungen, Antworten oder beides.
Das möchte ich unterstützen ein Szenario, in dem der Daten-generator (entweder den client im Falle von Streaming-Anfrage, oder den server im Falle von Streaming-Antwort Schreiben können, der auf dem stream. Wird diese unterstützt?

Die Analogie ist die Antwort.Ausgabestrom von einem ASP.NET Anfrage. In ASPNET, jede Seite aufrufen kann Schreiben auf den Ausgabe-stream, und der Inhalt wird vom client empfangen. Kann ich etwas tun, ähnlich wie in einer WCF-service - aufrufen Schreiben auf einen stream, der vom client empfangen wurden?

Lassen Sie mich erklären, mit einem WCF-illustration. Das einfachste Beispiel für Streaming in WCF ist der service-Rücksendung eines FileStream auf einen client. Dies ist einer Streaming-Reaktion. Der server-code, um dies zu implementieren, ist wie folgt:

[ServiceContract]
public interface IStreamService
{
    [OperationContract]
    Stream GetData(string fileName);
}
public class StreamService : IStreamService
{
    public Stream GetData(string filename)
    {
        return new FileStream(filename, FileMode.Open)
    }
}

- Und der client-code ist so:

StreamDemo.StreamServiceClient client = 
    new WcfStreamDemoClient.StreamDemo.StreamServiceClient();
Stream str = client.GetData(@"c:\path\on\server\myfile.dat");
do {
  b = str.ReadByte(); //read next byte from stream
  ...
} while (b != -1);

(Beispiel entnommen aus http://blog.joachim.at/?p=33)

Klar, oder? Gibt der server den Stream an den client, und der client ruft darauf zu Lesen.

Ist es möglich, den client an einen Bach, und dem server aufrufen auf ihm Schreiben?

In anderen Worten, anstatt ein pull-Modell - wo zieht der client Daten vom server - es ist ein push-Modell, bei dem der client stellt die "sink" - Strom und der server schreibt in Sie. Der server-seitige code könnte ungefähr so Aussehen:

[ServiceContract]
public interface IStreamWriterService
{
    [OperationContract]
    void SendData(Stream clientProvidedWritableStream);
}
public class DataService : IStreamWriterService
{
    public void GetData(Stream s)
    {
        do {
          byte[] chunk = GetNextChunk();
          s.Write(chunk,0, chunk.Length);
        } while (chunk.Length > 0); 
    }
}

Ist das möglich in der WCF ist, und wenn ja, wie? Was sind die config-Einstellungen, die erforderlich sind für die Bindung, interface, etc? Was ist Terminologie?

Vielleicht ist es nur Arbeit? (Ich habe es nicht ausprobiert)

Dank.

InformationsquelleAutor Cheeso | 2010-04-28

9

Ich bin ziemlich sicher, dass es keine Kombination von WCF-Bindungen, die Ihnen erlauben, um buchstäblich schreiben an die Clients streamen. Es scheint logisch, dass es angesichts der Tatsache, dass irgendwo unter der Oberfläche gibt es definitiv zu einem NetworkStream, aber sobald Sie beginnen, hinzufügen von Verschlüsselung und alle, die Spaß Sachen, WCF müsste wissen, wie zu wickeln diesen Strom, um es wiederum in die "echte" Nachricht, die ich glaube nicht, dass es funktioniert.

Jedoch die I-need-to-return-a-stream-aber-Komponenten-X-will-zu-schreiben-zu-eins-Szenario ist die häufigste, und ich habe eine catch-all-Lösung, die ich für dieses Szenario zu schaffen, eine zwei-Wege-Strom und erzeugen Sie einen worker-thread zu schreiben. Die einfachste und sicherste Weg, dies zu tun (und damit meine ich, die Art und Weise beinhaltet, dass das schreiben des least-code und daher am wenigsten buggy) ist die Verwendung von anonymen pipes.

Hier ist ein Beispiel für eine Methode, die zurückgibt einen AnonymousPipeClientStream, die verwendet werden können in WCF-Nachrichten, MVC Ergebnisse, und so weiter - wo immer Sie wollen, zum umkehren der Richtung:
```
static Stream GetPipedStream(Action<Stream> writeAction)
{
    AnonymousPipeServerStream pipeServer = new AnonymousPipeServerStream();
    ThreadPool.QueueUserWorkItem(s =>
    {
        using (pipeServer)
        {
            writeAction(pipeServer);
            pipeServer.WaitForPipeDrain();
        }
    });
    return new AnonymousPipeClientStream(PipeDirection.In, pipeServer.ClientSafePipeHandle);
}
```
Beispiel dafür wäre:
```
static Stream GetTestStream()
{
    string data = "The quick brown fox jumps over the lazy dog.";
    return GetPipedStream(s =>
    {
        StreamWriter writer = new StreamWriter(s);
        writer.AutoFlush = true;
        for (int i = 0; i < 50; i++)
        {
            Thread.Sleep(50);
            writer.WriteLine(data);
        }
    });
}
```
Nur zwei Vorbehalte zu diesem Ansatz:
1. Wird es scheitern, wenn die writeAction alles tut, um über den Bach (das ist der Grund, warum die test-Methode nicht wirklich entsorgt StreamWriter - denn das würde über den zugrunde liegenden stream);
2. Könnte es scheitern, wenn die writeAction eigentlich nicht schreiben, keine Daten, da WaitForPipeDrain sofort zurück und erstellen Sie eine race-Bedingung. (Wenn dies ist ein Anliegen, können Sie code, die ein wenig mehr defensiv um dies zu vermeiden, aber es erschwert die Sache noch viel für einen seltenen Grenzfall.)
Hoffentlich, die hilft, in Ihrem speziellen Fall.
- P. S. ich sollte Hinzugefügt haben, werden in der Antwort - Bestandsaufnahme, wie viele Daten wirklich benötigt werden gestreamt. Dies ist nützlich, um mehrere MB oder mehr, aber wenn Sie nur bekommen habe ein paar KB zu senden, dann würde es weniger Kosten, einfach ein MemoryStream für Ihre Komponente zu schreiben und dann wieder das.
- Boah, ja!. Jetzt lassen Sie mich das verstehen. Bitte bestätigen; (1) Die AnonymousPipe{Client,Server} - Stream ist ein paar Klassen, die verwendet werden auf server-Seite nur. (2) Was an den client zurückgegeben wird, ist ein System.IO.Stream.
- ps: ich habe diese Frage gestellt, bevor, finden Sie unter stackoverflow.com/questions/1499520 . Ich bin sehr froh, dass eine Allgemeine, einfache Antwort.
- Absolut, anonyme pipes kann verwendet werden, cross-Prozess, aber Sie sind perfekt für die in-Prozess verwenden. Sie sind nicht so "slim" wie ein reines Gewinde-Ansatz, aber bei sehr großen strömen wird der overhead trivial. Und (2) absolut, die PipeStream Klassen alle steigen aus System.IO.Stream.
- vielen Dank für die Einsicht. Mehr q ' s: Was meinst du mit "Reine Gewinde-Ansatz"? Vorausgesetzt, wir haben die I-need-to-return-a-stream-aber-Komponenten-X-will-zu-schreiben-zu-eins-situation, wie du es formuliert hast, konnte ich mir nicht vorstellen, eine Lösung, die nicht um einen bg thread, und einige Signalisierung zu koordinieren, die liest & schreibt. Ich hatte eigentlich geschrieben, ein adapter Strom, um das Problem anzugehen, aber es war nicht verhärtet und es war waaay mehr code als ich besitzen wollte. Diese anon-pipe-Ansatz scheint einfach und leicht. Also-was bin ich mit dem "pure-Gewinde-Ansatz"?
- Sorry, wenn das war ein wenig vage. Was ich meinte mit "reinen " threaded" war eine Lösung, die verwendet nur threads und Synchronisations-primitive, das wäre einfacher als eine anonyme pipe (das ist eine Globale Ressource). Wahrscheinlich etwas ähnliches wie der adapter, den Sie beschreiben. Wenn Sie zu Bearbeiten hatte, 500 Transaktionen pro Sekunde, dann wäre ich vielleicht vorsichtig sein, mit einer Pfeife, das ist alles, was ich meinte.
- gotcha, danke.
- Es gibt einen schweren bug in der oben GetPipedStream() Umsetzung. Lange Geschichte kurz: new AnonymousPipeClientStream(pipeServer.GetClientHandleAsString()) wird, erstellen Sie eine zweite SafeHandle bezieht sich auf die gleiche handle-Wert, was potenziell zu einer völlig anderen Griff befreit zu werden, wenn der GC abholen, dass SafeHandle (das gleiche handle-Wert haben kann, wurde wieder an diesem Punkt, weil die ersten SafeHandle bereits veröffentlicht). Fix: verwenden Sie new AnonymousPipeClientStream(PipeDirection.In, pipeServer.ClientSafePipeHandle) statt. Ich werde Bearbeiten Sie die Antwort.
- Beachten Sie, dass, wenn eine Ausnahme entweicht der lambda-Ausdruck übergeben QueueUserWorkItem der Prozess wird beendet. Dies ist wahrscheinlich, da die Leitung wird unterbrochen, wenn der client die Verbindung trennt, während Sie noch schreiben, die Antwort.
InformationsquelleAutor Aaronaught
2

WCF streaming funktioniert in beide Richtungen - Ihre Kunden hochladen können, Zeug in einem Bach, aber Ihre WCF-service kann auch senden Zeug in einem Bach. Sie kann definitiv schreiben Sie einen Dienst, dass die streams wieder große Dateien anhand Ihrer Datei namens oder einer ID oder so - absolut.

Wenn Sie möchten, senden die Daten zurück aus dem service, die Sie brauchen, dies zu tun in der Rückgabewert von Ihrem service-Methode, die muss der Typ Stream - Sie kann nicht (soweit ich weiß) "Angebot" einen stream zum schreiben in die WCF-Dienst erstellen einer Antwort-Datenstrom aus und senden Sie es zurück.

Haben Sie ausgecheckt haben, MSDN Streaming Message Transfer oder David Wood blog-post oder Kjell-Sverre blog-post auf WCF streaming? Sie sind alle sehr schön zeigen, welche config-Einstellungen, die Sie benötigen (im Grunde die Einstellung der TransferMode in Ihrer Bindung config Streamed, StreamedRequest oder StreamedResponse).
- So, Marc, was du sagst ... für einen gestreamt Antwort, ein Dienst muss wieder ein Stream an den client. In anderen Worten, es gibt keine direkten analogen für das ASPNET-Reaktion.Ausgabestrom, dass ein Dienst schreiben konnte direkt in. Richtig?
- richtig, der Dienst muss wieder ein Stream, aber nicht nur schreiben auf einen stream im client - der server und der client haben keine stehende Verbindung im WCF - alles, was Sie tun können, ist exchange-Nachrichten serialisiert (als ganzes oder in aufgeteilter Weise wie mit streaming)
InformationsquelleAutor marc_s

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.