ugrás a tartalomhoz

Nagyméretű fájlok feltöltése, letöltése korlátozásokkal

nevemrock · 2010. Ápr. 15. (Cs), 16.50
Üdv weblabor tagok!

Kaptam egy érdekes munkahelyi feladatot és a helyes fejlesztési irányvonal meghatározásához kéne néhány információ, egy kis segítség tőletek Guruktól. Néztem a keresőben nem találtam ilyen témát.

A feladat:
Nagy méretű fájlok (max.: 2G) feltöltésének és a letöltésének a korlátozása hostonként eltérő paraméterekkel.

Ami érdekelne:
Mik a lehetőségek PHP, Python szinten (Ti melyiket javasoljátok a program elkészítéshez)

Milyen szoftvereket kéne telepíteni a Debian-os szerverre amivel meg tudom oldani ezeket a korlátozásokat.

PHP beállításokat ismerem, de ha van valami extrém a 2GB os fájloknál, ne tartsd.

Nem konkrét megvalósításra vágyok, inkább csak ötletekre, amiért nagyon hálás volnék!
 
1

Lehet

janoszen · 2010. Ápr. 15. (Cs), 23.16
  • Lehetséges ilyesmit csinálni, bár alapvetően a szervert kell tudni tekergetni.
  • Arra érdemes figyelni, hogy az alatta levő fájlrendszer támogassa az ilyen méretű fájlokat, különben nyilván nem fog menni.
  • Ha olyan nyelvben valósítod meg a feladatot, ami saját maga hozzáfér a nyers POST adatokhoz (Python, Perl) akkor még azt is megteheted, hogy on the fly dolgozod föl az egészet.
  • Természetesen ha ilyen szolgáltatást indítasz, akkor érdemes valami Flash uploadert is csinálni, különben a kedves user nem tudja, hol tart a feltöltés.
  • Nagyon gondolkozz el azon, hogy nem írsz-e inkább egy specializált kliens alkalmazást hozzá hogy a user tudja folytatni a megszakadt feltöltést.
  • Összegezve: bármit is csinálsz, beszélj előtte a rendszergazdával.
2

Debian szerver

nevemrock · 2010. Ápr. 16. (P), 05.20
Köszi a választ. (benned bíztam)

Alapvetően egy Debian OS-el (Lenny; Apache2; PHP5; gondolom van Python is) megpakolt szerver szolgálná ki, a feltöltéseket. Rendszergazda nincs, vagy mintha nem is lenne (ködmön szindróma). Root hozzáférés van, tehát be tudom állítani.

Flash feltöltős cuccos van, lesz is használva.

A desktop alkalmazáson gondolkoztam, de sok biztonsági kérdést hordoz magában. Maga a program nem egy túl bonyolult dolog.

megjegyzés:
Én nem indítanák ilyen szolgáltatást, az egyszer biztos, mert szerintem ebben semmi poén nincsen sőt még veszélyes is. Ha nem tudsz jobbat csinálni a DropBox-nál akkor felejtős a dolog :) (márpedig nem tudsz) De mint írtam munkahelyi ez egy feladat.

Kérdés:
Apache2 mod_bw; mod_ipsecurity modulokkal van tapasztalatod? Mennyire alkalmas a korlátozásos részének a megoldására?
3

Nem tudsz shapelni

janoszen · 2010. Ápr. 16. (P), 09.01
Majd irok rendes postot is ha gepkozelben vagyok. Eloljaroban annyit, hogy felfele szerintem nem tudsz ertelmesen shapelni. Lefele meg bontsd chunkokra a fajlt es sleepelj a darabok kozott. A mod_bw pont ezt csinalja.
4

Rendes post

janoszen · 2010. Ápr. 16. (P), 11.18
Na, rendes post. Nem találtam meg a mod_ipsecurityt, esetleg adsz egy linket róla? Ez egyébként tipikusan az a projekt, amit nem fogsz tudni kész modulokból összelapátolni hanem kénytelen vagy megismerni, az adott modulok mit (nem) csinálnak.
5

Rendetlen post

nevemrock · 2010. Ápr. 16. (P), 17.58
Köszi az tippeket, ennek segítségével megvan a fejlesztési irányvonal :)

mod_cband vagy mod_bw; mod_slotlimit ezekkel próbálom megoldani a fel és letöltés korlátozását.

A mod_ip..-t azért nem találtad, mert hajnali kómában megtoldottam az IP szóval. mod_security - de ez nem fog kelleni (úgy néz ki).

Az igazság az, hogy mindig kifogom az ilyen projekteket, de nem zavar, mert egy csomót tanulhat belőle az ember.

Olvastam Én is ezt a sleep-es megoldást de nekem nem tetszik. Valamiért ódzkodok ilyen utasításokat használni, mikor minden a sebességről szól.

-----
Dúrvamód várjuk ám a múltkor beharangozott cikked!
6

Poen

janoszen · 2010. Ápr. 16. (P), 18.40
Ha tenyleg akarsz vele haladni en nem vagyok ellensege egy szemelyes talalkozonak sem hogy vegigbeszeljuk a rendszer oldalat a dolognak.

--

A cikk keszuloben van es igazabol tobb cikk lesz mert nagyon sok az anyag. Meg rendezem ossze.
8

"en nem vagyok ellensege egy

nevemrock · 2010. Ápr. 16. (P), 19.52
"en nem vagyok ellensege egy szemelyes talalkozonak sem hogy vegigbeszeljuk a rendszer"

Nagyon köszi, rendes tőled ez a felajánlás (és a szavadon foglak - csak idő kérdése!), de sínen van a dolog!
7

Gép előtt

janoszen · 2010. Ápr. 16. (P), 19.27
Na, megint gép elé értem. Szóval a mod_bw, mod_cband, stb pontosan ugyanazt a sleepet csinálja, mint Te. Ha nem hiszed, nézd meg a forráskódot. Az egyetlen opció a Linux tc tekergetése lenne annak érdekében, hogy hatékonyabb legyen. A dologtól teljesen függetlenül technológiailag nem működhet másképp, mint hogy chunkokban küldöd a dolgot. Persze csinálhatod azt is, hogy nem korlátozol és a felhasználó gyorsan föl-le transzferálja a cuccát és előbb takarodik el a vonalból. Annál is inkább fölösleges szivatnod a usert ilyesmivel, mert a fölfele vonala a legtöbb embernek kevesebb, mint a mennyire Te rakod a korlátot.
9

"A dologtól teljesen

nevemrock · 2010. Ápr. 16. (P), 20.17
"A dologtól teljesen függetlenül technológiailag"

"chunkokban küldöd a dolgot" - oké a dolog, de miért nem tolhatom ki neki a teljes fájlt? (memória? 1G lesz a feltölthető fájl korlát)


Én ezzel a USER 'tással' párhuzamosan magamat is szivatom, sőt megkockáztatom a tervezett szolgáltatás népszerűsége ezen a ponton el is dőlt. De ez és még néhány dolog, kifejezetten igény. pl.: letöltés korlátozása IP alapján (kevesebb szál;napi limit)

Én személy szerint nem korlátoznám a feltöltés illetve a letöltést. De ha tudnád milyen erőforrás hiányos környezetbe kell megvalósítani azt hiszem vagy sírnál, vagy halálra nevetnéd magad , de egy hátast mindenképpen dobnál.
10

Várjál

janoszen · 2010. Ápr. 16. (P), 23.12
Na várjál. Én a lefele irányról beszéltem. Fölfele nem tudsz értelmesen shapelni mert a hozzád érkező irányba nem látod a send queuet, a TCPwindow méretet lehet csökkenteni ami a küldendő adatmennyiséget lehet csökkenteni a másik gépet, ennek viszont hatalmas késleltetése van és egyéb problémák is vannak vele.

Összefoglalva: a letöltés oldalon tudsz korlátozni, a feltöltés oldalon nem.
11

Desktop program

nevemrock · 2010. Ápr. 17. (Szo), 09.04
Ennél a résznél érzem a hasznát a desktop alkalmazásnak.
Elindulok az Apache modulokkal és meglátom meddig jut a mutatvány.

Nagyon köszi az infókat, igazán sokat segítettél.
12

Hajra

janoszen · 2010. Ápr. 17. (Szo), 09.48
Sok sikert. Ha elakadtok, kerdezzetek.
13

Üzletileg

janoszen · 2010. Ápr. 17. (Szo), 10.12
Közben eszembe jutott, hogy üzletileg azért sokszorosan lábon lövi magát a társaság, aki ezt üzemeltetni akarja. a Dropbox sikereinek a titka részben az, hogy van hozzá olyan eszköz amivel nem kell webes felületet bűvölni hanem sima mappaként tudod használni. Ha még magyar piacra is szól a dolog akkor nagyon valószínű hogy a belefektetett pénzt sem hozza vissza.
14

(üzletileg és jogilag) Nem a kutyák dolga

nevemrock · 2010. Ápr. 17. (Szo), 19.47
Igen ezzel én is tisztában vagyok, de szerencsére ez nem a "kutyák" dolga.
Az én dolgom az, hogy elkészítsem ezt az Über faca rendszert.

Én ezzel az egésszel úgy vagyok, ha nincs elég erőforrásod rá, akkor az egész nem ér semmit. Ahogy ezt a projektet átgondoltam Én semmi poént nem látok benne, de ez megint nem a kutyulik doga->(a programozós alias suszter maradjon a kaptafájánál.).

DropBox:
Igen a Desktop program az egyik előnye ('Dropbox Popsikereinek'), a másik mint a (Ubuntu One) esetében is a titkosított adat tárolás, ami valljuk be egy ilyen rendszernél nem utolsó szempont.

Nagy valószínűséggel a DropBox-ot nem egy ember fejleszti :), és van háttere is a dolognak.

Ha elakadok kereslek (köszi)!
15

Találtam valamit

janoszen · 2010. Ápr. 19. (H), 15.49
Szia megint!

Találtam valamit a fölfele forgalom shapeléséhez: http://www.linuximq.net/faq.html

Kicsit experimentalnak néz ki de akár jó is lehet.

János
16

shapeléséhez

nevemrock · 2010. Ápr. 21. (Sze), 19.49
Szia,

Köszi, linket érdekesnek és ígéretesnek tűnik (remélem nem kell használni :).

Jövő héten indul a móka 1. fázisa kiváncsi leszek hogy muzsikálnak az Apache modulok.
Ha nem lesz más igény akkor CI PHP keretrendszer lesz az alapja, (Jó volna Yii de durván nem értek hozzá, bár a végére megtanulnám). Ma csináltam az egészről egy elmetérképet, ami inkább elmebajhoz hasonlított a végére, hát lesz mint megvalósítani (virtuális fájlrendszer + hozzá egy fájlkezelő UI, nem lesz unatkozás :).

arth2o
17

Hááát

janoszen · 2010. Ápr. 21. (Sze), 21.41
Egy kis építő kritikát engedj meg. Ha akarod elfogadod, ha nem akarod nem.

Az a probléma, hogy a webfejlesztő szakmában hajlamosak az emberek minden feladatot szögnek nézni (mert van kalapács, avagy a PHP). Erre a feladatra valószínűleg bármilyen frameworköt használsz, kevéssé alkalmas. Nem annyira azért mert távol áll tőle hanem azért mert a későbbiekben mindenféle oprendszer-közeli dolog belefejlesztése igen nehéz lesz. Tudom, hogy vízzel kell főzni és gyorsan kell összerakni de hosszabb távon a saját szakmai előrehaladásod érdekében lehet, hogy érdemes belekostolni a Perl vagy Python nyelvekbe és megnézegetni, hogy néz ki az oprendszer oldala a feladatoknak. Ha ez a tudásod meglenne, lehet hogy sokkal gyorsabban és mindamellett hatékonyabban tudnád megoldani a mostani feladatot.

Ami a Yii frameworköt illeti, az elődjéhez (a Pradohoz) volt/van szerencsétlenségem. A legnagyobb rákfenéje, hogy mindent egy úgynevezett pagestate-el akar megoldani ami gyakorlatilag eliminálja a kliens-oldali programozás szükségességét és egyben a HTTP protokoll egyik lényeges tulajdonságát igyekszik kikerülni. Ezzel semmi baj nem volna, ha a rendszer néhány jól irányzott refreshtől és back gombtól nem ijedne meg annyira hogy kidobja a "pagestate corrupt" oldalt és abban a sessionben már semmire nem hajlandó.
18

a háát az fáj most egy picit

nevemrock · 2010. Ápr. 22. (Cs), 19.30
Ami a framework-öt illeti igazad van, sok helyen megköti az ember kezét és még lassít is a dolgon (csak a sebesség miatt egy pici saját keretre cserélve).

Python-hoz értek és szeretem is. Sokkal kiforrottabb és hatékonyabb nyelvnek tartom mint a PHP-t szívesen használnék csak azt (de ezzel a többi PHP fejlesztőt kilőném a sorból - nem tudnának hozzányúlni). Jól látod néhány Python szkriptet írnom kell amivel aktuális rendszer információkat kérek le és ehhez igazítom a várakozás folyamatát, idejét.

Oprendszer, szerver oldalról némileg ismerem a Linuxot, régóta Ubuntut használok (-és rendszergazdi jogsim is van :), de a legfontosabb hogy amit csinálok az érdekel is (ha nem akkor gáz van).

Köszi az építő kritikát, sokat segítettél!
Ne fogd vissza magad a jövőben sem :)
19

Ha nekem kellene csinálni...

janoszen · 2010. Ápr. 22. (Cs), 19.50
Ha nekem kellene ilyen szolgáltatást csinálnom valszeg valami WebDAV irányába nézelődnék. Annál is inkább, mert van egy csomó technológia ami hellyel-közzel már erre épül. Igaz, nem forrott ki igazán sosem, de még Windowsban is van rá kliens. Aztán persze lehet webes frontendet is gyártani. Lehet, hogy ennek megvalósításához első körben csak egy nagyon pici autentikációs modult kell írnod Perlben az Apachehoz és már működik is és valószínűleg nagyon sokáig elég is lesz.

Amivel az igazi bajod lesz és semmiképp ne hanyagold el, az a fájlok száma. Simán előfordulhat az, hogy egy user betölt 10000 fájlt egy könyvtárba és utána jön panaszkodni, hogy lassú. Ergó mindenképpen valahogy mappelned kéne a fájlokat, erre viszont adatbázist kell építeni amit a maga oldaláról nem árt particionálni ha értelmes tempóval akarsz benne keresni.

Természetesen azt is eljátszhatod, hogy lősz magadnak egy olyan fájlrendszert ahol ez nem probléma de nem tudnék neked kapásból ajánlani ilyesmit.

Nagyjából ennyi, ami hirtelen eszembe jutott.
20

Fel kell kötnöm a gatyát, az

nevemrock · 2010. Ápr. 22. (Cs), 20.45
Fel kell kötnöm a gatyát, az aranyos, érdekes projekt kezd szörnyeteggé válni (olyan mint a Lost-ban a Lock).

Ez a WebDAV-os dolog tényleg érdekes és egyszerűsítene néhány dolgot.

Adatbázis MySQL lesz (SQlite3 is szimpi de túl sok az adat). Van valami tipped a témakörben?
21

MySQL

janoszen · 2010. Ápr. 22. (Cs), 21.12
A MySQL jó dolog, eleinte biztos nem lesznek gondok. Azt javaslom, hogy tarts egy index táblát, ami megmondja, melyik user melyik táblában található és a fájljait már onnan nézd ki. Mivel dinamikusan bővíthető, nem valószínű hogy bármikor is problémáid lennének a fájlok számával.

A tényleges fájlokat meg tárold valami hash szerint, a metaadatok adatbázisából meg hivatkozz rá. Esetleg ha van lehetőségetek rá, nézzétek meg valamelyik zFS-t támogató oprendszert (Solaris, *BSD) és tegyetek be gyors diskeket a gyakran használt fájloknak.

Ha nincs lehetőségetek ellenben van valami barriereket támogató RAID vezérlőtök, álljatok át Ext4-re, az jót tesz a performanciának. Viszont figyeljetek oda, hogy támogassa a barriereket különben áramszünet után majd nagyot néztek.

Ja igen, a memcached jó dolog, használjátok sűrűn, használjátok sokat, a memória olcsó és igen nagyon meggyorsítja a kiszolgálást ha nem kell MySQL-ben turkálni. Ha keresni akartok benne, akkor nézzetek valami key-value storet, mint pl Keyspace (magyar fejlesztés ha jól tudom) vagy az Apache Cassandra.
22

helyzetjelentés

nevemrock · 2010. Ápr. 30. (P), 06.36
A dolog 1. fázisával megvagyok, ingyenes fel és letöltés némi limittel.
Voltak érdekes dolgok, ami kiakasztott az ez IE böngészőcsalád de ez nem újdonság.
Design tili-toli fázisban van a dolog.

Nagy segítség a http://www.plupload.com/. Adatbázis, Memcache be van használva. A cuccos elvileg gyorsabb mint a jelenleg piacon lévő eszközök (eddig :)

De most jön az izgalmasabb rész, mikor tömegével tehetik ugyanezt, csoportokra korlátozva. Kontra no erőforrás.
23

Terheles

janoszen · 2010. Ápr. 30. (P), 08.47
Ha tudsz ra tesztelo scriptet irni es BIXre van kotve a cucc, jopar megabitnyi tesztet ra tudok ereszteni.