[ASP.NET] grote files/stream

[Verwijderd]

Hallo allemaal,

Ik heb een ASP file upload script, met this.[fileinputfieldname].PostedFile, maar het script wordt pas gestart wanneer alles binnen is. Dat maakt het uploaden van bestanden van bijv. een paar GB redelijk onmogelijk, laat staan intussen de progressie monitoren.

De vraag is:

Hoe stel ik in dat het script aan de slag gaat VOORDAT de hele request binnen is? Ik kan wel met Request.binaryRead aan de slag gaan, maar op dat moment is (volgens mij) alle data al binnen, en staat er dus ergens onnodig een enorme buffer/tmpfile te rotten.

Is er een manier om de hele zaak wat eerder te onderscheppen, of moet ik dan toch maar iets anders gaan verzinnen?

[gorgi_19]

Overweeg eens om een apart 3rd party component hiervoor te gebruiken; met de standaard functionaliteit ga je het niet redden.

[lier]

Zou je je verhaal ook in begrijpelijke taal kunnen schrijven ? (Ik ben maar een simpele .NET ontwikkelaar...).

Misschien kan je eens vertellen wat je aan het bouwen bent, welke versie je ervoor gebruikt, webservice/webapp, enz.

[Niemand_Anders]

HTTP is stateless. De browser verstuurd een verzoek naat de webserver en de webserver stuurt een process terug. Er is geen tweeweg communicatie mogelijk tussen client en webserver. Verder hebben de meeste webservers een standaard limiet van 4mb per post.

HTTP is dan ook niet bedoeld om grote bestanden te down- of uploaden. Daarvoor is het File Transfer Protocol (FTP) uitgevonden.

Er zijn wel componenten die een tweede request enforcen via een 'PUT' methode. Je kunt eens kijken naar AbcUpload. Die heeft ook de mogelijkheid om een progresbar te tonen.

[Hydra]

Gebruik anders iets als een applet voor de upload? Kun je prima een progressbar laten zien. Aangezien een .aspx pagina pas aangeroepen wordt op het moment dat de hele HTTP request binnen is, gaat dit niet zondermeer lukken. Daarnaast gaat je browser ook eerst die bak data verstouwen en gaat daarna eens nadenken over de HTML die eventueel teruggestuurd wordt.

Niemand_Anders schreef op vrijdag 13 juli 2007 @ 16:28:
HTTP is dan ook niet bedoeld om grote bestanden te down- of uploaden. Daarvoor is het File Transfer Protocol (FTP) uitgevonden.

Beetje loos. HTTP is prima geschikt om grote bestanden te uploaden mits de webserver dit wil accepteren. FTP gebruiken is sowieso in webapplicaties over het algemeen niet mogelijk; veel gebruikers zitten achter een proxy.

[ Voor 39% gewijzigd door Hydra op 14-07-2007 17:04 ]

[_Thanatos_]

Niet vergeten dat de webserver 3x de grootte van de file in het geheugen moet kunnen hebben... 1x om het ruwe request op te eten, 1x om het te parsen en 1x om er iets mee te doen (naar database, naar disk, naar prullenbak, etc).

Ik heb gewerkt met uploads van enkele tientallen MB's, en meerdere gebruikers deden dat vaak tegelijk. Dit ging goed, vanaf het moment dat we 2GB geheugen in die server hadden geprikt. Daarvoor haakte het ding het ene na het andere request af.

Een paar GB uploaden zou ik daarom NIET doen. In theorie kan het, maar HTTP is niet geschikt voor een upload van zulke amplitude.

[Not Pingu]

Hydra schreef op zaterdag 14 juli 2007 @ 17:03:
Beetje loos. HTTP is prima geschikt om grote bestanden te uploaden mits de webserver dit wil accepteren. FTP gebruiken is sowieso in webapplicaties over het algemeen niet mogelijk; veel gebruikers zitten achter een proxy.

Als je via HTTP bestanden van meerdere gigabytes wilt overzetten, krijg je sowieso problemen.
Zonder 3rd party componenten is het onmogelijk om transfers in gedeeltes te doen. Stel je transfer gaat na 1.5gb fout, dan heb je pech en kun je overnieuw beginnen.
Kun je wel transfers opdelen in stukken, dan zit je nog altijd met de gigantische overhead die het HTTP protocol heeft.

Dat argument van gebruikers achter proxies of firewalls gaat hier ook niet echt op, want als ze achter een proxy zitten is de kans klein dat gigantische HTTP transfers worden toegestaan.

[MrBucket]

Na aanleiding van het topic AJAX - taal? library? api? of techniek? zat ik me te bedenken: kun je niet het XMLHttpRequest object gebruiken om blokken van een paar honderd kb naar de server te posten?

Toegegeven, het zal wel een beetje pielen worden, ook omdat je aan de client kant een manier moet vinden om het bestand in blokken in te lezen (misschien dat je wat met het FileSystemObject kunt). En aan de server kant zul je alle ontvangen blokken weer bij elkaar moeten rapen.

--edit
Het onderste script op deze pagina biedt conversiemogelijkheden om strings die met het FileSystemObject zijn uitgelezen als binair te behandelen. Kan ook handig zijn

Geen idee of dit haalbaar is hoor, maar 't zou een mogelijke ingang kunnen zijn.

[ Voor 13% gewijzigd door MrBucket op 15-07-2007 21:09 ]

[sopsop]

Je zult dan met clientside javascript bestanden op de locale machine moeten gaan lezen, dat lijkt me security technisch niet mogelijk. Het zou alleen mogelijk zijn indien de gebruiker handmatig de blokken gaat selecteren.

[ Voor 24% gewijzigd door sopsop op 16-07-2007 08:54 ]

[MrSleeves]

MrBucket schreef op zondag 15 juli 2007 @ 20:55:
Na aanleiding van het topic AJAX - taal? library? api? of techniek? zat ik me te bedenken: kun je niet het XMLHttpRequest object gebruiken om blokken van een paar honderd kb naar de server te posten?

Zoiets had ik ook gevonden, je moet het bestand in stukjes uploaden. Of anders een 3rd party component. Voor mij was het niet zo interessant dus ik gebruik de normale upload. Door de maxRequestLength in httpRuntime (web.config) die door mijn provider vast op 10 MB staat, kan ik toch niet meer dan dat in één keer uploaden.

[Verwijderd]

Hartelijk dank tot zover!

Voor het verzenden van de uploads is er al een flash-ding. Die kan de progressbar voor zijn rekening nemen bij het verzenden. Het is vooral de limiet die ik wil omzeilen, en vooral het volledig inladen van de buffer. Is het dan echt niet mogelijk om met ASP (.net) buffertjes te lezen voordat ze klaar zijn?

Ik heb vooral een PHP achtergrond, dus het hele ASP is een tikkie nieuw voor mij. Al die soorten projecten en soorten files (asax, aspx, etc etc etc) zeggen me al weinig. Weet iemand daar misschien een mooi uitlegverhaal voor, overigens?

Met PHP zou ik een (fast)CGI dingetje maken die de data uit de stdin stream leest en in kleine brokjes opslaat. Zoiets moet met ASP toch ook wel kunnen lijk me ?

Hoe doen 3rd party controls het dan?
Ik had er wel 1 gevonden, maar VS2005 wou hem niet eens importeren. Was een ouder formaat oid.

Ik gebruik C# met VS 2005.

[Hydra]

Is het niet een idee om die bestanden in blokken te verzenden? Want in 1 keer een bestand van 1GB uploaden is iets waar je sowieso een custom handler voor zou moeten schrijven vermoed ik, standaard wordt namelijk die hele file in het geheugen gelezen voordat 'ie weggeschreven wordt. Heb het zelf wel eens met files van 60+ MB gedaan, en daar werd je al niet blij.

[Not Pingu]

Verwijderd schreef op maandag 16 juli 2007 @ 17:54:
Hartelijk dank tot zover!

Voor het verzenden van de uploads is er al een flash-ding. Die kan de progressbar voor zijn rekening nemen bij het verzenden. Het is vooral de limiet die ik wil omzeilen, en vooral het volledig inladen van de buffer. Is het dan echt niet mogelijk om met ASP (.net) buffertjes te lezen voordat ze klaar zijn?

Met (ASP).NET is dat wel mogelijk, alleen kan je webserver geen HTTP requests opdelen over meerdere delen. Dat is je grote probleem hier. Je hebt hoe dan ook een component nodig aan de clientside (dit kan een Java applet zijn, maar geen Javascript/AJAX) die je file asynchroon aan het HTTP verkeer kan versturen. Hoe je de voortgang van je upload kunt uitlezen hangt dan af van het component dat je gebruikt. Leuk dat je al een progressbar hebt, maar dat is een beetje andersom werken zeg maar

[MrBucket]

Not Pingu schreef op maandag 16 juli 2007 @ 20:10:
Je hebt hoe dan ook een component nodig aan de clientside (dit kan een Java applet zijn, maar geen Javascript/AJAX) die je file asynchroon aan het HTTP verkeer kan versturen.

Waarom kan dat niet, dan?

Het lijkt me trouwens dat een Java applet standaard ook niet bij het lokale filesysteem mag?

[Hydra]

MrBucket schreef op maandag 16 juli 2007 @ 20:56:

Het lijkt me trouwens dat een Java applet standaard ook niet bij het lokale filesysteem mag?

Klopt, maar je kunt dat wel vrij makkelijk voor mekaar krijgen, moet alleen de gebruiker wel aangeven dat 'ie je vertrouwd.