[Alg] Hoe file uploads throttlen*

[Verwijderd]

Ik moet van een opdrachtgever een upload dienst ontwikkelen. De opdracht is als volgt: "Er moeten bestanden geupload/gedownload worden met vooraf vastgestelde snelheden en groottes in overeenstemming met actieve abonemment.". Nou is deze dienst al heel snel te realiseren met FTP maar dan heb je niet zo'n mooie gelikte AJAX webinterface.

Nu heb ik voor deze dienst al bijna het technisch ontwerp af maar ik krijg een aantal dingen niet rond:
- Uploadsnelheid throttlen op actief abonemment. Apache modules zoals mod_throttle en mod_bandwidth volstaan niet hier. De nadruk ligt op "Dynamisch" omdat abonemmenten ook uit een database komen.
- Bestandsgrootte checken voor upload. Wederom niet iets wat apache rond kan krijgen omdat bestanden eerst geupload worden en dan gechecked.

De meeste van deze problemen lijken mij buiten het domain van Apache/php te liggen. Is het echt nodig om een Java applet / servlet te schrijven? of heeft iemand een minder tijdrovende oplossing/alternatief?

Er zijn oplossingen voor deze problemen maar dan moet ik via de shell verschillende pakketen op OS niveau regelen. Dit geeft mijn pakket een erg grote achilles hiel ivm hackers. Dus liever deze optie als last-resort te beschouwen.

Ik schuw nieuwe programmeer talen niet, dus heb je ervaringen in andere talen laat het weten. Bij voorbaat dank voor jullie input.

[? ?]

gewoon filetje uitlezen in een loop: 1kB uitspuwgen, beetje wachten
zo deed ik het denk ik om 100MB te 'streamen' aan 5KB/s

[BtM909]

era.zer schreef op maandag 31 maart 2008 @ 11:28:
gewoon filetje uitlezen in een loop: 1kB uitspuwgen, beetje wachten
zo deed ik het denk ik om 100MB te 'streamen' aan 5KB/s

Ook voor upload?

---

Verzin een beter beschrijvende titel en request even een topic title change via

[ Voor 93% gewijzigd door BtM909 op 31-03-2008 11:30 ]

[? ?]

Ooow, euh nee. sry
Ik denk niet dat dat gaat in PHP.

In ASP.NET (in JSP ook) kun je dat wel, daar kun je direct aan de uploadstream en ze byte per byte uitlezen aan jouw tempo. Uploadgrootte kun je soieso niet checken voordat het bestand binnen is.
Als ik een header toevoeg met Content-Length: 100 en blijf verder sturen na de 100 bytes, dan zal dat waarschijnlijk wel lukken

trouwens heel raar om de upload te cappen

[ Voor 47% gewijzigd door ? ? op 31-03-2008 11:34 ]

[Voutloos]

Cappen kan natuurlijk ook op een andere manier: upload gewoon lekker volle bak, en zorg daarna voor een periode van inactiviteit zodat het gemiddelde weer goed komt.

Geen ideale oplossing, maar het is dan ook niet een ideale requirement.

[Kettrick]

Kan je de apache mod_* niet toepassen op verschillende vhosts, en deze als target gebruiken in je forms? Je kan dan in het uploadscript bekijken of de client geauthorizeerd is om die vhost ( en dus snelheid) te gebruiken.

[Verwijderd]

De apache modules zijn niet echt een optie, deze zijn te statish. Ik zal nog eerder de firewall dynamisch wijzigen. Maar ik wil shellscript ten alle kosten vermijden.

ASP = IIS => Prijskaartje (en gevolgschade )

Uploads moeten gewoon ook in de gaten gehouden worden ivm kwaliteitsbewaking.

[TeeDee]

Verwijderd schreef op maandag 31 maart 2008 @ 12:03:
ASP = IIS => Prijskaartje (en gevolgschade )

ASP.NET = Mono = *nix

Voutloos schreef op maandag 31 maart 2008 @ 12:50:
Alsof Mono de Oplossing voor Alles is.

Dat zeg ik toch ook niet?

Het heeft veel meer nut om het daadwerkelijk over die requirements te hebben en mogelijke implementaties dan over een nagemaakt framework dat op tal van punten niet stabiel of compleet is.

Deal

Afaik kan PHP niet aan de RAW_POST_DATA komen. Deze kan je wel bekijken, maar er staat niks bijzonders in. Je zou kunnen kijken naar PHP Ajax Upload of een andere als Mega Upload. Mega Upload bijvoorbeeld maakt gebruik van Perl / PHP.

Bij PHP Ajax Upload kan je een array[bytes_uploaded] aan roepen. Op basis daarvan kan je met wat hackwerk ook een upload afkappen. Of van te voren checken op de max_file_size. Dan zit je imho alleen nog specifiek met het bandwith throttling. Hier heb ik in ieder geval nog geen idee over.

[ Voor 111% gewijzigd door TeeDee op 31-03-2008 13:11 ]

[Voutloos]

Alsof Mono de Oplossing voor Alles is.

Het heeft veel meer nut om het daadwerkelijk over die requirements te hebben en mogelijke implementaties dan over een nagemaakt framework dat op tal van punten niet stabiel of compleet is.

[ZpAz]

swfupload maakt gebruik van flash om dingen up te loaden, nu heb ik geen ervaring met flash, maar zou je daarin niet de upload kunnen cappen?

[ Voor 3% gewijzigd door ZpAz op 31-03-2008 14:53 ]

[Verwijderd]

Dit lost wel één van mijn problemen op, leuke suggestie maar ik betwijfel of het throttling gedeelte mogelijk is.

[? ?]

Alles op client is onveilig, dus enkel cappen op server niveau.
de requeststream in asp.net is veruit de beste oplossing, wat is een paar honder euro als je zo'n service wil gaan aanbieden? Je werkt met abonnementen, dus heb je inkomsten. Amateurs maken sites die niets mogen kosten.. en ik neem aan dat jij ook niet voor niks werkt!

[Verwijderd]

Ik ben bang dat ik mijn bazen er niet van kan overtuigen om een Windows Server licentie te pakken puur en alleen omdat we dan meer "beheersbaarheid" hebben. Het zou teveel kosten voor deze 2 baten.

Verder word FreeBSD+Apache+PHP ook al langer gebruikt, dus hier gaat de voorkeur naar uit. Aan programeer taal kan ik wel afwijken, ook apache modules zijn mogelijk.

[Verwijderd]

Eens met era.zer. Als je dit commercieel doet dan mag je best kosten maken.

Je kunt met ASP.NET zelf een http handler maken voor requests. Deze handler zou dan a.d.h.v. de querystring of sessie informatie de juiste gegevens uit de database kunnen halen en terug kunnen sturen als bestand. Op die manier kun je zelf de snelheid in de hand houden.

Ik weet niet wat je requirements precies zijn, maar waarom wil je de uploadsnelheid beperken? Dit betekent dat de klant de browser onnodig lang open moet hebben staan. Het lijkt mij veel beter om een x aantal megabytes per tijdseenheid te kunnen uploaden. Dan heeft de klant wel een limiet, maar wel volle uploadsnelheid.

Edit: Windows Server 2008 Web Edition kost een paar honderd euro. Maargoed, je klant bepaalt uiteindelijk waar je het mee moet doen. Bovenstaand verhaal gaat trouwens ook redelijk op voor PHP.

[ Voor 12% gewijzigd door Verwijderd op 31-03-2008 15:50 ]

[Verwijderd]

Verwijderd schreef op maandag 31 maart 2008 @ 15:47:
Ik weet niet wat je requirements precies zijn, maar waarom wil je de uploadsnelheid beperken? Dit betekent dat de klant de browser onnodig lang open moet hebben staan. Het lijkt mij veel beter om een x aantal megabytes per tijdseenheid te kunnen uploaden. Dan heeft de klant wel een limiet, maar wel volle uploadsnelheid.

Bijna het zelfde, maakt qua tijdsduur dus niets uit.


Het gaat ook om de extra softwarepakketten die op de server moeten komen. Deze zijn niet voor windows beschikbaar. Ik ga wel zowiezo naar deze oplossing kijken.

[Verwijderd]

Verwijderd schreef op maandag 31 maart 2008 @ 15:55:
[...]
Bijna het zelfde, maakt qua tijdsduur dus niets uit.

Ik denk dat je m'n punt niet begrijpt. Stel de klant mag 70 megabyte per uur uploaden. De snelheidsbeperking zet je dan op 20 kB/s zodat een klant nooit meer dan 70 megabyte per uur kan uploaden. Dit betekent wel dat de klant een uur de browser open moet hebben staan. Als je op de server bijhoudt hoeveel megabyte geupload is, dan kun je de snelheidsbeperking eraf halen en bijhouden hoeveel megabyte de klant geupload heeft. Zo gaat het uploaden sneller en is de tijd dat de browser open moet staan korter.

Als hij bijvoorbeeld de daglimiet overschrijdt, dan zeg je tegen de klant dat hij morgen weer moet proberen met uploaden als hij al 70 x 24 megabyte heeft geupload die dag.

[ Voor 8% gewijzigd door Verwijderd op 31-03-2008 17:10 ]

[Verwijderd]

Hmmm, ik begreep je inderdaad niet. Dit is een heel slim alternatief bedankt!

[moozzuzz]

Verwijderd schreef op maandag 31 maart 2008 @ 17:09:
[...]

Ik denk dat je m'n punt niet begrijpt.

Wellicht hoopt de klant echter dat z'n abbonnees over z'n bandbreedte gespreid kunnen worden, terwijl dit met jouw methode minder te garanderen valt.

[Verwijderd]

moozzuzz schreef op maandag 31 maart 2008 @ 18:07:
[...]
Wellicht hoopt de klant echter dat z'n abbonnees over z'n bandbreedte gespreid kunnen worden, terwijl dit met jouw methode minder te garanderen valt.

Dat is maar gedeeltelijk waar. De kans op pieken bestaat altijd, maar die pieken zijn vaak niet een probleem. De verstookte bandbreedte wordt vaak per maand bepaald en dan wordt er dus een gemiddelde genomen. De voornaamste reden om upload van gebruikers te beperken is eerder de opslagcapaciteit van de server dan bandbreedte, maar dat hoeft in dit geval natuurlijk niet.

Welke methode je ook kiest, je moet er altijd voor zorgen dat vitale applicaties op de server niet slachtoffer worden van een verstopte lijn.

[ Voor 10% gewijzigd door Verwijderd op 31-03-2008 18:47 ]

[Johnny]

moozzuzz schreef op maandag 31 maart 2008 @ 18:07:
[...]
Wellicht hoopt de klant echter dat z'n abbonnees over z'n bandbreedte gespreid kunnen worden, terwijl dit met jouw methode minder te garanderen valt.

Meer verbindingen voor langere tijd open houden terwijl er afwisselend op verschillende plaatsen data wordt weggeschreven zorgt waarschijnlijk een zwaardere belasting van het systeem terwijl in totaal dezelfde hoeveelheid bandbreedte wordt gebruikt.

[Janoz]

Verwijderd schreef op maandag 31 maart 2008 @ 18:45:
[...]

Dat is maar gedeeltelijk waar. De kans op pieken bestaat altijd, maar die pieken zijn vaak niet een probleem. De verstookte bandbreedte wordt vaak per maand bepaald en dan wordt er dus een gemiddelde genomen. De voornaamste reden om upload van gebruikers te beperken is eerder de opslagcapaciteit van de server dan bandbreedte, maar dat hoeft in dit geval natuurlijk niet.

Welke methode je ook kiest, je moet er altijd voor zorgen dat vitale applicaties op de server niet slachtoffer worden van een verstopte lijn.

Voor een betere spreiding zou je ook nog kunnen overwegen dat het uploaden binnen bepaalde tijd ranges voor de halve prijs gaat. Uploaden na 22:00 en voor 6:00 tellen bijvoorbeeld maar voor de helft mee.

[Voutloos]

Verwijderd schreef op maandag 31 maart 2008 @ 17:14:
Hmmm, ik begreep je inderdaad niet. Dit is een heel slim alternatief bedankt!

Gelukkig had ik dat al niet lang en breed gezegd.