Vlákno názorů k článku Broadbandu se v ČR moc nedaří: ADSL/VDSL přibývá stále pomaleji, kabelu dokonce ubývá od Nmkcz - Posila Vam babicka buchty telegramem?

Posila Vam babicka buchty telegramem?

Nemuzu nez vrele souhlasit, copak si nekdo bude stehovat byt postou? Nebo jeste lepe, dorucuje se uhli telegramem? Mozna by stacilo, kdyby si lidi pamatovali z cehoze ty zkratky pochazeji Simple Mail Transfer Protocol - jednoduchy protokol prenosu ZPRAV, File Transfer Protocol - protokol prenosu SOUBORU! PS: Ta dnesni mladez by vazne nebyla bez porna schopna Sit pouzivat - kazdy vi, ze pouze diky nemu je Sit rychlejsi a rychlejsi a rychlejsi

Pokud si s nekym vymenuju citliva data, dohodnu si snim i odpovidajici zpusob - trebas pristup na firemni ftp. V 99% firem to stejne nikdo neresi a firemni data se vesele posilaji maily, klido se uploaduji na verejna uloziste ...

Jop, mam zcela osobni zkuseno s uzivatelkou, ktera se strasne divila, ze "ji ty fotky z firemni akce nejdou poslat" ... nacez sem zjistil, ze se do mailu snazi prilozt 5GB fotek ... a rozeslat to asi 150 lidem ... (=srv by to samozrejme posilal kazdemu zvlast, coz je dalsi nevyhoda mailu).

Zcela konkretni mailserver jen velmi vyjimecne pouziva zcela jediny uzivatel. A takovy mailserver na ktery denne chodi desitky tisic mailu bude mit jiste hromadu nadsenych useru, kdyz jim pulden neprijde/neodejde zadny mail, protoze se srv bude zabyvat vasi gigovou prilohou. Jeste nadsenejsi budou v pripade, ze spojeni v prubehu prenosu nekolikrat padne, a srv bude mail prenaset znova.

O kodovani mailu uz rec byla, spousta jinych protokolu pouziva komprese, prilohy se zipuji ... a proc asi ... mail z historickych duvodu pouziva kodovani jake pouziva, takze jakakoli priloha naroste o temer 50%.

Ještě lépe: Zkuste přes veřejné úložiště předat firemní soubory kolegovi. A je jedno, jestli je to zašifrované. Téměř jistě tím porušíte firemní směrnici se všemi důsledky pro sebe. Je paradoxní, že na e-mail se firemní směrnice nevztahuje. A firmemní úložiště dat je přístupné jen z intranetu.

Můžeme dumat o idiocii byrokracie, ale nezměníme ji.

Pořád směšujete obecný problém "posílám velký soubor nevím komu nevím kudy a nevím, jak to bude stahovat" a konkretní situaci "vím přesně, komu velký soubor posílám". Aplikace a protokoly v konkrétních případech fungují. Best practices jsou psány defenzivně, "protože to občas nemusí fungovat, tak to nedělej nikdy".

cokoli, co pošleš na veřejné úložiště, se stává veřejným msjetkem, nikdo ti totiž nezaručí, že tvoje data nebudou ukradena, nebo zničena, na náhradu škody nemáš nárok, protože provozovatel uložiště za nic neručí a odmítá jakoukoli odpovědnost. Kliknutím na ano toto odsouhlasuješ, kliknutím na ne nic neuložíš. Takže pokud jste hazardéři a na vašich datech vám nezáleží, klidně cloudujte až se budou hory zelenat. Až budete stát přd soudem za porušování autorského (zmetkového) zákona, můžete nadávat jen sami na sebe. Ale nadarmo se neříká: chytrému napověz, hloupého kopni!

1/ Co bych asi tak s tvým HD videem dělal? To, co mne zajímá v HD není a hned tak nebude. 2/ jak víš, že to nebudu mít kam uložit? 3/ Pošleš to na cloud, (jakýkoli), zaplatíš hafo peněz protože takto velký soubor nikam zdarma nenacpeš a než se z toho posílání a komplikací s tím spojených stačíš vzpamatovat, budou ti policajti obracet, na základě udání z BSA, nebo jiné podobné práskačské instituce, kvartýr vzhůru nohama. Tohle mi, naštěstí, nehrozí, protože v naší síti se nešpehuje a nebonzuje, zvenku se do ní nikdo nedostane, protože je kompletně zašifrovaná a proti nežádoucímu průniku hardwarově chráněná. A, jak už jsem napsal výše, větší objemy dat mailem neposílám, takže jsi, jako obvykle, silně mimo mísu.

No, pokud ten váš původní příspěvek, na který jsem reagoval, říkal "jsou případy, kdy to nedělat", tak to jste měl samozřejmě pravdu a já vás jen nepochopil. Na mě to ale působilo, jako byste tvrdil "někdy je to problém a proto je to lepší nedělat nikdy", a na to jsem cítil potřebu se ozvat.

Rozumím vám, ale mícháte dohromady dvě různé věci. Existují určitě debilní uživatelé, kteří bez rozmyslu posílají na všechny strany nesmyslné přílohy. Ale stejně tak existují legitimní důvody, aby uživatel A poslal uživateli B velký soubor, a proč v tom případě nepoužít mail?

Kakonos, seres si do vlasni huby, posilat prilohu v mailu je prasarna i na Gbit pripojce. Poslu ti HD video jako BMP stream, OK? Co na tom ze to bude mit nekolik TB, co je mi do toho ze to nemas kam ulozit ...

Neuč orla létat :)

Reagoval jsem na vyse uvedene nesmysly, ktere jsem se snazil uvest na pravou miru. Neni-li zajem, vnucovat se nebudu ;-)

Kdyz vas to tedy zajima, tak nevim. Muzu vas ovsem ujistit, ze vyse uvedene odpovedi by znely stejne i v pripade, ze bych p. Krska znal.

Kdyz vstupujete do diskuse, radce si ji nejprve prostudovat celou a nevytrhavat vety z kontextu. Predmetem diskuse nebyly nejake proprietarni bezdratove spoje na giganticke vzdalenosti, ale bezne dostupna pevna a mobilni sit. Mechanismy vami citovane, pokud je mi znamo, neimplementuje ani SSL/TLS verze protokolu IMAP/SMTP&POP ci HTTP(s). Pricemz netvrdim, ze to je technicky nemozne.

Mejte hezky den.

Trochu O. T. ale: kladivem zatlučený vrut, pokud je to do dřeva, drží stejně dobře, jako zašroubovaný. Tedy, když se to umí.

Podle vás by tedy asi bylo nejlepší funkci Přidat přílohu ve všech mailových klientech zrušit a donutit platící ovečky, aby si připláceli za něco tak pofidérního, jako je cloud? děkuji, už jsem zvracel! Což takhle donutit opy, aby konečně začli za nehorázné peníze, o které většinu z nás odrbávají, konečně začli poskytovat také přiměřeně kvalitní služby? Jenže to by nebylo ,,demokratické", že?

Data v cloudu = data v čoudu! Viz Megaupload! Takže soubory zašifruji, pošlu přes Skype přímo a jsem v klidu. Zkuste na nějaký cloud uložit zdarma a bez rizika ztráty, nebo ,,vytěžení" přes 5 GB souborů, což reprezentuje jeden film, nebo cca 7 hudebních CD. Ono to číslo vypadá bůhvíjak astronomicky, ale v reálu to nic moc není.

Cemu na vete, kterou jste citoval, nerozumite? Zivot je daleko pestrejsi, nez si leckdo umi predstavit.
Dejme tomu, ze mate objektivne vysoce nespolehlive prenosové prostredí a potrebujete komunikovat s databazi (neprilis intenzivne, ale s rychlou reakci). Prikladem takoveho prostredi budiz radiove systemy pro komunikaci na vetsi vzdalenosti, napriklad s mobilnimi uzivateli v terenu, kde neni GSM nebo neco podobneho.
TCP potrebuje navazit spojeni a za provozu se vykecava - dohaduje velikost okna, timeouty atd. No a kdyz kazdy treti - ctvrty paket prijde poskozeny (cili segment se ztrati) vysledek je ten, na vlastni data temer nedojde; TCP ma nejaky ten stavovy diagram a tak.
V danem pripade se po rade experimentu jako nejlepsi reseni ukazalo prejit na UDP a spolehlivost se osetrit prave v ramci vytvorene aplikace.

Nedávno jsem posílal do Brna přes 5 GB dat! Přes Skype a trvalo to něco málo přes 20 minut. A co je, podle Vás, pane Krsek, rozumné? podle mne je rozumné to, co potřebuji, ne to, co si myslí ISP. (My nejlépe víme, co náš zákazník potřebuje -to už tady bylo a jak se zdá, je to tu místy ještě pořád.)

Docela by mne zajimalo, jestli vite, kdo je p. Krsek ;-).

"pokud budu komunikaci vesti po UDP, musi si aplikace krome jinych veci zajistit i to zjistovani, zda data dorazila nebo nedorazila"

Tady nepomuze ani svecena voda.

Mejte hezky den.

Tady nepomuze ani svecena voda.

Mejte hezky den.

Vzhledem ke zvolenemu nicku presne plati "a kdo neumi, tak to uci" TCP je protokol nad IP vrstvou(technicky muze behat klido i nad uplne jinou), ktery zarucuje (= dostane se vam potvrzenky) narozdil od UDP, ktera nezarucuje (nedostane se potvrzenky) spojeni. Nic vic.

Zjevne vubec netusite, jaky je rozdil mezi IP paketem a TCP/UDP paketem (mohou byt samozrejme i dalsi, napr ICMP ...) a matlate to vsechno dohromady.

Tudiz male skoleni - pokud budu komunikaci vesti po UDP, musi si aplikace krome jinych veci zajistit i to zjistovani, zda data dorazila nebo nedorazila (pokud to neni jedno, coz se vyuziva pomerne casto). Pokud se pouziva TCP, tak se aplikace o doruceni dat dozvi "od prirody", coz ale stale neznamena, ze se v pripade, ze data dorucena nejsou nemusi "nejak" zachovat.

Mno a tady dochazime k tomu, ze v pripade rekneme ftp v sobe tento protokol primo obsahuje moznost navazat prenos tam, kde skoncil, ktezto v pripade mailu nezbyva nic jineho, nez zacit posilat znova.

Problematika posilani nesmyslnych priloh je problem debilnich uzivatelu, nema nic spolecneho s operatory a jinymi uzivateli, kteri jsou za to nuceni platit, protoze tu nic jineho neni.

"tcp vam "zajistuje" tak maximalne doruceni konkretnich paketu"

Jak jsem psal vyse, podivejte se, jak je dana vymena dat realizovana (referencni model ISO/OSI, TCP protokol). Az to nastudujete, tak se hned zastydite, co jste to napsal za hloupost.

Vysvetleni: TCP protokol (az na vyjimky) neprenasi IP pakety. Naopak, segmenty TCP protokolu jsou zapouzdreny uvnitr IP paketu (datove pole). Co se vlastnosti (funkci) protokolu TCP tyce, tak mi verte, ze to vase "maximalne" by se dalo nahradit pomerne rozsahlou publikaci :-)

OSI model muze pusobit usmevne, ale pokud nekdo nerozlisuje pojmy jako komunikacni protokol, komunikacni vrstva a aplikace, je dobre ho odkazat na principialni zaklady, aby se pojmy "vystribrily" a bylo mozne diskutovat vecne :-)

Mejte hezky den.

Zkuste si nekdy poridit to "mobilni spojeni". Rukama mi prosly vsechny dostupne mobilni platformy a ve vsech bylo vzdy vychozi nastaveni mailoveho klienta "Stahovat pouze zahlavi". Prilohu si tak stahnete az tehdy, pokud to opravdu potrebujete a vyzadate si to.

Pozn.: Problematika 100MB FUP je problem uzivatelu, ne operatoru, protoze uzivatele jsou za to ochotni platit (osobne jiz za to neplatim, wifi mam v okoli dostatek). Je to ale vyhradne muj pristup a chapu, ze jini maji jine naroky.

"proto nepisu o protokolu, ale o aplikacich"

Vase predstava o aplikaci je mi zahadou. Kazdopadne faktem je, ze aplikace vyuzivaji protokoly aplikacnich vrstev ke komunikaci, a ty zase vzdy protokoly nizsich vrstev. Mrknete, jak funguje referencni model ISO/OSI.

Pokud se nekomu rozpada spojeni na aplikacni vrstve a nema moznost aplikaci jako takovou "donutit to nedelat", pak doporucuju zmenu aplikace/prostredi.

Pokud ani jedno nejde a dany clovek potrebuje setrit kazdy preneseny kilobit, doporucuji pouzit stary dobry kabelovy prenos; Vezme se velka kabela, do ni se nandaji prislusne datove nosice a ta se prijemci doruci. Jinak plati vyse uvedene.

Melete tu kraviny, tcp vam "zajistuje" tak maximalne doruceni konkretnich paketu, ale ne celyho souboru. Pokud spojeni zbuchne (coz je presne to, co vam zarucuje TCP - ze se dovite ze to zbuchlo), tak v pripade mailu muzete zacit odesilat znova, protoze navazani je veci protokolu o uroven vejs.

Provnani naprosto sedi, normalni lidi taky neprevazej 10t pisku skodovkou.

Mno, rek bych ze tech "starejch" pardalu je nastesti pomerne dost, takze takovy mail nad 10MB prakticky nema sanci projit vubec nikde. On totiz nekdo s "mobilnim" spojenim bude opravdu nadsen kdyz se mu pri jeho 100MB FUB (a 100Kbitech) zacne sosat 20MB mail ...

+1 Nelze nez nesouhlasit :-)

"spolehlivost nahravani, potrebujete nejakou kombinaci klient/server"

Motate tu pate pres devate. Spolehlivost prenosu (reliability) je zajistena transportnim protokolem, tedy TCP. Jestli je do nej zapouzdren HTTP nebo IMAP/SMTP&POP je z hlediska spolehlivosti irelevantni.

Pokud vam TCP spojeni hostingovy server resetuje a vy ho potrebujete znovunavazat, pak si sam odporujete a metoda "nahrat na server" misto "odeslat mailem" ma tudiz pomerne velkou nevyhodu. Jeste se mi nestalo, ze by mi TCP spojeni resetoval mailovy server.

V dnesni dobe klidne desetimegovy soubor mailem poslu, neni s tim absolutne zadny problem, pokud s tim prijemce souhlasi. Pokud prijemce preferuje nejaky freehosting, poslu to touto cestou a heslo s URL mu poslu mailem.

Prirovnani s kladivem a sroubovakem je samozrejme k vyse uvedenemu naprosto mimo misu.

Jinými slovy, protože staří vlivní internetoví pardálové myšlenkově stále ještě žijí na konci minulého století.

Resume mě zajímá, pouze pokud mám netriviální množství spadlých spojení na lince. Base64 mě zajímá, pokud musím počítat každý bajt (kvůli ceně nebo kvůli pomalosti spojení). Best current practices je dokument psaný velmi zkušenými lidmi, kteří své zkušenosti pracně nabrali před deseti lety a pevně věří, že jsou stále ještě platné.

Asi už budete jiná generace :-). Nicméně takto dlouhé maily už mohou odmítat poštovní servery, administrátoři nemusí vždy uvažovat "rozumně".

Tak napriklad grafikovi posilam podklad tak je pro me zdlouhave soubor nekam ulozit/ nahrat a pote poslat link. Obvlast pokud ten soubor bude potreba jen jednou - to bych zas musel hlidat zda si soubor stahnul abych jej mohl smazat. Navic email ma pro me vetsi vyhodu v tom, ze si jsem schopen dohledat co jsem k danemu podkladu psal (jednoznacne email poznam diky priloze) a mam to archivovane v odeslane poste kterou mazu a ponechavam si posledni kvartal.

Jinak i to FTP ackoli lze posilat keepalive packet tak se mi nepodarilo soubor nahrat. Po kabelu muzu vyuzit pouze O2 (cca 7km od Pardubic a upload 512KBit), takhle jsem pripojen pres wifi - na vesnici jedina moznost :-(

Docela dobrou veci, ktera by se mela brat v potaz je i rychlost uploadu pokud budem uvazovat ze vse budeme mit casem na internetovem ulozisti (nechci psat cloudu abych nedrazdil strouraly co by si chteli rypnout na tema cloud).

Ono je pekne ze nam roste rychlost rychlost downloadu (me staci stabilni 4Mbit/sec), ale pokud mi O2 da jen 512Kbit/sec tak dekuju, nemam zajem. Dnes bych povazoval vysokorychlostni internet od 5Mbit/sec a 2.5Mbit/sec upload (proste polovina rychlosti uploadu).

Mozna nekoho napadne proc rychlost uploadu by mela byt meritkem rychleho internetu. Zkusili jste si nekdy odeslat soubor o 10MB a pri odesilani 98% vam klient (Thunderbird) zdeli ,ze vyprsel casovy limit. To same muze platit pro FTP apod.