Téléchargement de fichier WCF à partir du client Silverlight

Question

J'essaye de télécharger des fichiers sur mon service WCF en utilisant la diffusion en continu pour télécharger de gros fichiers. Tout cela fonctionne très bien en utilisant un client normal (comme une page ASP.net). Dans Silverlight cependant, je reçois l'erreur suivante: Les délais d'attente ne sont pas pris en charge sur ce flux

Je télécharge via un flux de mémoire et je suppose que le problème est essentiellement parce qu'au lieu d'appeler la méthode synchrone dans Silverlight, je suis obligé d'appeler l'async méthode. Donc, c'est ce qui n'aime pas le flux de mémoire normal. J'ai essayé de trouver un autre flux à utiliser mais il semble que soit ils ne sont pas supportés par Silverlight (bufferedstream, networkstream), soit ils cassent la méthode (stream générique qui DOIT être le seul paramètre de la méthode à utiliser). Est-ce que j'ai râté quelque chose? Au départ, j'utilisais un tableau d'octets, mais il y a trop de limitations de taille pour ce que je dois autoriser à télécharger.

Je peux insérer mon code ici mais puisque tout fonctionne parfaitement avec mon client de test ASP.net, je suppose que mes liaisons et le code sont corrects.

Answer 1

Il y a trois questions distinctes ici:

1) Peut-on utiliser le type de flux dans votre contrat?

2) Pouvez-vous obtenir un vrai comportement de streaming sur le client? (Par exemple télécharger un fichier de 2 Go sans allouer 2 Go de mémoire n'importe où dans la pile - y compris la pile HTTP sous-jacente)

3) Pouvez-vous obtenir un vrai comportement de streaming sur le serveur? Autant que je me souvienne, les réponses à # 1 et # 2 sont "non" dans Silverlight (même si cela peut avoir changé dans SL4.0). Donc, le meilleur que vous pouvez réaliser est # 3. Par exemple, vous pouvez essayer une astuce avec un contrat basé sur byte [] sur le côté Silverlight qui aboutit à la même projection XML qu'un contrat basé sur Stream sur le côté serveur. Ou, avez byte [] du côté client et lisez directement à partir de la classe Message du côté serveur. Mais mon souvenir sur # 1/# 2 peut être faux ...