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 Vasek - Docela dobrou veci, ktera by se mela brat...
-
Vasek (neregistrovaný)
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.
-
Petr (neregistrovaný)
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é.
-
Dekuji za oznaceni "stary vlivny internetovy pardal" (bylo-li mysleno na me). Stary se sice obcas citim, ale napriklad v zemi vychazejiciho slunce bych vekem mohl byt sotva nekde ve strednim managementu a muj vliv moc nevybocuje z vlivu bezneho prazaka :-)
Mozna Vam uniklo, ze dotycny diskutujici zminoval netrivialni mnozstvi spadlych spojeni. Dale bylo v clanku i v diskusi zminen "mechanismus" FUP, ktery znamena, ze uzivatele pocitaji kazdy bajt ...
Takze, co tam mate dal?
-
Petr (neregistrovaný)
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.
-
Pan ucitel (neregistrovaný)
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.
-
krakonoš (neregistrovaný)
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?
-
krakonoš (neregistrovaný)
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.
-
Petr (neregistrovaný)
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".
-
x (neregistrovaný)
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%.
-
x (neregistrovaný)
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).
-
Vasek (neregistrovaný)
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 :-(
-
Mozna Vas to prekvapi, ale pouziti nejakeho ulozneho webu muze dobu nahravani zkratit (i kdyz ani http neni dokonaly protokol pro ukladani).
Duvod je ten, ze pokud odesilate e-mail, tak je jeho obsah zakodovan do base64 kodovani, ktere zvetsuje velikost odesilaneho baliku dat radove o desitky procent.
Co se tyce spolehlivost nahravani, potrebujete nejakou kombinaci klient/server, ktera umoznuje znovunavazat na preruseny prenos.
Jinak jsem dalek toho, abych Vam neco narizoval, pouzivejte to, co se Vam libi (at je to jiz rozumne, ci nikolivek). Jen upozornuju na to, ze srouby je lepsi utahovat sroubovakem nebo pouzivat kladivo (nicmene i s kladivem se muze spoj povest).
-
Pan ucitel (neregistrovaný)
"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.
-
Vidite a ja jsem umyslne napsal to, co jsem napsal :-) proto nepisu o protokolu, ale o aplikacich. Mrknete, jak funguje znovunavazani na preruseny prenos treba u winscp. Stejna aplikace umoznuje na spadle spojeni znovunavazat.
Co se tyce vyresetovani TCP spojeni, zapominate na takovou drobnost, jakou je spolehlivost nekterych siti. To, ze mam na stole gigabit, v labu desitku, jeste neznamena, ze si nejsem vedom, ze par kilometru ode me maji uzivatele na vyber mezi dial-upem, EDGE a sousedskou WiFi, jejiz kvalita je v obci proslula.
Sroub a kladivo je uder "primo na hlavicku" :-)
-
Pan ucitel (neregistrovaný)
"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.
-
x (neregistrovaný)
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.
-
Pan ucitel (neregistrovaný)
"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 :-)
-
x (neregistrovaný)
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.
-
Jarda (neregistrovaný)
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. -
Pan ucitel (neregistrovaný)
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.
-
krakonoš (neregistrovaný)
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!
-
Petr (neregistrovaný)
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.
-
krakonoš (neregistrovaný)
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.)
-
Dobry den,
vedome pro jednou porusuji svoje pravidlo DNFT.Ja take pouzivam obcas Skype pro posilani vetsich objemu dat, ackoliv to neni vzdy optimalni. A to v pripade, ze ma jedna ze stran verejnou adresu.
Jinak moje ambice nejsou uzivatelum neco narizovat. Nicmene pokud se nasledne uzivatele divi, ze jim neco nefunguje, dovolim si jim sdelit vlastni nazor. Jinymi slovy - ten samozrezny sroub do dreva nakonec obvykle kladivem zatlucete, ale neni jiste, ze tam bude vzdycky poradne drzet.
V dokonale ucte
Michal Krsek -
Nmkcz (neregistrovaný)
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
-
Mailem to za nějakých okolností jít může a není to zrovna rychlost. Omezení jsou poštovní servery, poštovní klienti a i to jaké služby si platí druhá strana.
Opravdu seriozní je používat nějaké datové úložiště , případně protokol pro přenos souborů. jistota přenosu , nepoškození dat nebo jejich kompromitace je podstatně vyšší.
-
krakonoš (neregistrovaný)
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í.
ČLÁNKY DO MAILU