[ASP.NET] Bestanden versturen mbv webservice

[Edsger]

Probleem: Ik wil met behulp van een webservice bestanden oversturen naar clients.

Bronnen: Ik heb al verschillende antwoorden gevonden op dit probleem op het internet, maar (uiteraard) was geen enkele oplossing naar mijn tevredenheid. In mijn opdracht kan ik ervanuit gaan dat
- .net framework op de server staat (en ook de client is in .net)
- bestanden zowel in simpele tekst als grote binairies

De meeste oplossing versturen bestanden gewoon als één brok data (volgens bronnen op internet), en dat wordt onacceptabel bij grote bestanden. Het liefst zou ik ook geen onderscheid willen maken tussen tekst en binaire bestanden zoals het geval is bij ftp.

Vraag: Welke techniek kan ik het beste gebruiken. Hoe verstuur ik dus bestanden op een manier waarbij ik gebruik maak van de webservice standaarden (dus in een soap bericht).

[yodax]

Je zou eventueel een byte array kunnen gebruiken als return value. Ik heb dit in een aantal situatie's gebruikt. Het werkt naar behoren.

[Edsger]

yodax schreef op 27 februari 2004 @ 10:46:
Je zou eventueel een byte array kunnen gebruiken als return value. Ik heb dit in een aantal situatie's gebruikt. Het werkt naar behoren.

Zo heb ik de tussentijdse oplossing geimplementeerd, echter is dit volgens verschillende bronnen op internet een minder geschikte oplossing voor het verzenden van grotere bestanden. Dit omdat alles dan in 1 keer gebufferd wordt door de webservice en dan pas verzonden. Zou je mij kunnen vertellen wat voor performance je haalt, bij wat voor soort omstandigheden?

[1sectionone1]

Kijk ook eens naar de Webservices Extensions (WSE). Daarin zit DIME Attachements waarbij je gewoon bestanden kan attachen aan je soap message (dit is gewoon binair).

Ik heb hiermee geen problemen ondervonden, ook met bestanden van enkele megabytes.

[yodax]

Mijn bestanden blijven onder de 1MB, de performance is zeer goed. Bijna hetzelfde als dat ze via een normale http stream verzonden zouden worden.

[Edsger]

1sectionone1 schreef op 27 februari 2004 @ 12:10:
Kijk ook eens naar de Webservices Extensions (WSE). Daarin zit DIME Attachements waarbij je gewoon bestanden kan attachen aan je soap message (dit is gewoon binair).

Ik heb hiermee geen problemen ondervonden, ook met bestanden van enkele megabytes.

Daar heb ik idd ook wat over gelezen alleen dat waren typsiche promotie - gericht aan managers - praatjes, maar moet je die WSE dan ook installeren op de client machine wil je gebruik maken van WSE?

[whoami]

Edsger schreef op 27 februari 2004 @ 12:03:
[...]


Zo heb ik de tussentijdse oplossing geimplementeerd, echter is dit volgens verschillende bronnen op internet een minder geschikte oplossing voor het verzenden van grotere bestanden. Dit omdat alles dan in 1 keer gebufferd wordt door de webservice en dan pas verzonden. Zou je mij kunnen vertellen wat voor performance je haalt, bij wat voor soort omstandigheden?

Kan je dat bufferen niet aan- en uitschakelen dmv het BufferRespons attribute:

code:

[WebMethod(BufferResponse=false)]
public void MijnWebMethod()
{
}

[1sectionone1]

Edsger schreef op 27 februari 2004 @ 12:47:
[...]


Daar heb ik idd ook wat over gelezen alleen dat waren typsiche promotie - gericht aan managers - praatjes, maar moet je die WSE dan ook installeren op de client machine wil je gebruik maken van WSE?

Ja het zijn weer nieuwe dingen die niet standaard zitten in het .NET Framework, en het moet dus ook op de client. Ik gebruik een server met .NET en een client met Visual Basic + SOAP Toolkit. Werkt goed samen, en het is ook mogelijk om meerdere attachments tegelijkertijd te verzenden.

[Edsger]

Met permissie van de moderators kom ik even terug op dit onderwerp.

Ik heb aan de hand van deze discussie de voor de handliggende oplossing gebruikt van het oversturen van bestanden mbv een byte array -= daarvoor nog bedankt =-. Alleen nu ik het geheel over een aantal weken moet gaan opleveren ben ik nog even terug gaan denken over het performance-issue. Even over die BufferResponse, dit is wat de MS documentatie erover schrijft:

The WebMethod attribute provides the following properties:

* BufferResponse – When set to true, the default setting, ASP.NET buffers the entire response before sending it to the client. The buffering is very efficient and helps improve performance by minimizing communication between the worker process and the Internet Information Services (IIS) process. When set to false, ASP.NET buffers the response in chunks of 16 KB. Typically, you set this property to false only if you do not want the entire contents of the response in memory at one time. For example, you are writing back a collection that is streaming its items out of a database.

Oke, dat is serverside, maar nu dus op de client. Op de client wordt ook eerst het hele bestand in een object gedeserialiseerd alvorens het naar de harde schijf geschreven wordt, toch? Ik kan me niet voorstellen dat .NET "even in de code vooruit kijkt wat er met de response gedaan zal worden".
Ik kan helaas dus niet de WSE extensies gebruiken omdat de client op willekeurige computers moet kunnen draaien.

Een tweede hieraan verwante vraag is hoe ik de voortgang van de download in de gaten kan houden. Eventueel als het eerste probleem is opgelost zou ik de bestandsgrootte in de gaten kunnen houden, of zijn er eventueel eenvoudigere methoden om de "downloadsnelheid" te monitoren?

[ Voor 4% gewijzigd door Edsger op 25-03-2004 10:41 ]

[whoami]

Kan je die webmethod niet asynchroon aanspreken?
Je spreekt de webmethod dan aan, je files worden asynchroon gedownloaded, en ondertussen kan je verder doen.
Als je files gedowned zijn, wordt er een callback uitgevoerd.

[Edsger]

Ik download mijn files asynchroon.

maar asynchroon of niet, als je het resultaat opvraagt zit het hele bestand als een byte array in het geheugen. Dan pas kan het je het gaan opslaan (voor zover ik weet).

[Edsger]

*bump*

[Nexopheus]

Is het niet wat om je bestanden te encoden met Yenc en vervolgens gewoon als plaintext over te sturen ?

Yenc biedt de mogelijkheid om een bestand in meerdere delen te verzenden, CRC of MD5 checksums.

Momenteel gebruik ik nog base64 voor het encoden van files, een Yenc lib is in de maak.

Ik gebruik overigens xmlrpc.net voor de communicatie.

[Edsger]

Ik zie niet in hoe dat mij zou moeten helpen.

Als ik een webservice functie aanroep krijg ik van het .Net framework het "resultaat" terug. Ook al wordt dat tussentijds in pakketjes verstuurd met yenc onderhuids.

Als Yenc echter op een hoger niveau werkt, zou ik meerdere functie aanroepen moeten doen lijkt me? Ik zie dan toch liever een oplossing waarbij de data naar de schrijf geschreven wordt bij het aanroepen van 1 functie, want ik zie yenc eerder dan als een hack (je hebt een oplossing en voor een klein detail op te lossen moet je "er een niveau tussen frotten").

[ Voor 4% gewijzigd door Edsger op 26-03-2004 12:31 ]

[Edsger]

*bump*