আমরা এখনও কেন এইরকম ছোট ইমেল সংযুক্তি ফাইল আকারের বিধিনিষেধ রাখি? [বন্ধ]


52

একে অপরের 1 জিবি ফাইল ইমেল করা থেকে গৌরবময় বছরে, প্রযুক্তিগত সীমাবদ্ধতাটি কী আমাদের আটকাচ্ছে?

বা এটি কেবল প্রধান ইমেল প্ল্যাটফর্মগুলি তাদের পা টেনে নিয়ে যাচ্ছে?

আমি যদি আমার ইনবক্সটি কেবলমাত্র শিরোনাম দখল করতে সেট করতে পারি এবং তারপরে আমি যদি পূর্ণ সংযুক্তিগুলি চাই, তবে সমস্যাটি কী?

আমার মনে হচ্ছে ইমেল সংযুক্তির আকারগুলি 1992 এ আটকে গেছে ...


23
1992-এ সংযুক্তি মাপ আটকে? Puh-leeze। 1992 এর যে কোনও পদ্ধতির মাধ্যমে আপনি একটি 50 এমবি ফাইল স্থানান্তরিত দেখতে দেখতে চাই , কোনও ই-মেইলে এটি যুক্ত করা যাক (হ্যাঁ, আমার এই চলতি মাসের 2011 থেকে এই জাতীয় বেশ কয়েকটি ইমেল রয়েছে, না, আমি আমি এটি সম্পর্কে খুব খুশি না)। ইঙ্গিত: পছন্দসই পদ্ধতিটি, 1992-এ, টেপে অনুলিপি করা এবং গন্তব্যে গাড়ি চালানো বা সম্ভবত একটি সারা রাত ডায়াল আপ এবং সেশন অন্তর্ভুক্ত থাকতে পারে। uucp
পিসকভোর

4
@ পিসকভোর: বিকল্পভাবে, বহু-ভলিউম-স্প্যানিং আরজ সংরক্ষণাগারযুক্ত ডিস্কে পূর্ণ একটি মুদি ব্যাগ। কিন্ডার সম্পর্কহীন: cs-exhibitions.uni-klu.ac.at/index.php?id=187
Sum1stolemyname

17
ব্যান্ডউইথ এর সাথে সামান্য বা কিছুই করার নেই; আপনার যদি কারও সাথে যোগাযোগ করতে হয় তবে তা 20 মেগাবাইটের চেয়ে বড়, ইমেল এটি প্রেরণের উপায় নয়
শাদুর

2
@ শাদুর: এটি অযাচিত মেলের ক্ষেত্রে ঘটে - একটি ই-মেইলে একটি লিঙ্ক (যা প্রাপক ক্লিক করতে বা না বেছে নিতে বেছে নেয়) চূড়ান্ত শেষে হাজার হাজার বাইট নেয়; একটি ই-মেইলে একটি সংযুক্ত ফাইলটি, বেশিরভাগ ক্ষেত্রেই, বিনা অনুরোধে ডাউনলোড করা হয় (আমি এই বিষয়ে আইএমএপি এর ক্ষমতা সম্পর্কে অবগত রয়েছি, তবে বেশিরভাগ ব্যবহারকারীদের "সবকিছু ডাউনলোড" করার জন্য এই সেট রয়েছে, যা কিছুটা ব্যান্ডউইথকে প্রভাবিত করবে - এছাড়াও ব্যবহৃত মেল ছাড়াও অন্য উদ্দেশ্যে: ব্রডব্যান্ডের আগে আইটি-নন ব্যবহারকারীদের স্বাভাবিক অভিযোগ: "আমার ওয়েবটি এত মন্থর কেন? হ্যাঁ, আমি বিসিসির 100 জন লোকের সাথে নৃত্যের পিগের সাথে একটি 10 ​​এমবি ইমেল পাঠিয়েছি, এটি কীভাবে প্রাসঙ্গিক? ")
পিসকভোর

4
@ পিসকভো "টেপ পূর্ণ একটি ট্রাকের ব্যান্ডউইথকে কখনই হ্রাস করবেন না"; আজকের মতো সত্য: আপনি> একটি টেপে > 1 টিবি পেতে পারেন ....
রিচার্ড

উত্তর:


163

সমস্যাটি হ'ল: ই-মেইল (এসএমটিপি / পিওপি 3 / আইএমএপি / হোয়াট-হু-ইউ-হ'ল) একটি প্রাচীন, সাধারণ প্রোটোকল যা মূলত বিশ্বস্ত নেটওয়ার্কে সাদামাটা বার্তা প্রেরণের জন্য উদ্দিষ্ট। আজকের ইন্টারনেট জুড়ে প্রচুর পরিমাণে বাইনারি ডেটা প্রেরণ বা গ্রহণের জন্য এটি ব্যবহার করা একটি বোল্টড অন হ্যাক, মূল ব্যবহারের ক্ষেত্রে থেকে সম্পূর্ণ আলাদা এবং এটি এই চরিত্রে বরং খারাপভাবে অভিনয় করে।

আপনি যখন ই-মেইলে কোনও ফাইল সংযুক্ত করেন, তখন এটি বেস 64-এনকোড হয়, যা এর আকার 1/3 দ্বারা বৃদ্ধি করে। সুতরাং, আপনার 1 জিবি ফাইল আরও 300 এমবি বড় হয়; এছাড়াও, ডাউনলোড প্রোটোকলে কোনও অন্তর্নির্মিত সংকোচনের ব্যবস্থা নেই, এভাবে স্থানান্তরকে গতিযুক্ত করার কোনও উপায় নেই (এবং কিছু ক্ষেত্রে (প্রেরণের জন্য এসএমটিপি, প্রাপ্তির জন্য পিওপি 3)) এমনকি ভাঙ্গা স্থানান্তর পুনরায় শুরু করার কোনও উপায় নেই - সংযোগটি 1.2 এ ভাঙ্গা হয়েছে জিবি? দুঃখিত, আপনাকে এগুলি আবারও প্রেরণ করতে হবে)। তদুপরি, এসএমটিপি হ'ল স্টোর এবং ফরোয়ার্ড প্রোটোকল। কি অনুমান? হ্যাঁ, সেই 1.3 জিবি ফাইলটি একাধিক সার্ভারে অনুলিপি করা দরকার; মেল সার্ভার প্রশাসকদের কাছ থেকে সীমাহীন সুখ।

1990 এর দশকে এটি কোনও সমস্যা ছিল, যখন কোনও কার্যকর বিকল্প ছিল না (এফটিপি? এইচটিটিপি / 1.0? পুহ-লিজ); তবে ২০১১ সালের গৌরবময় বছরে, মেঘের কাছে / নিরবিচ্ছিন্নভাবে ডেটা আপ / ডাউনলোড করার বিভিন্ন উপায় সহ (যেমন, ড্রপবক্স, উবুন্টু ওয়ান, অ্যামাজন এস 3, সর্বাধিক পরিচিত নামটির নাম), এর বাহানা "এটি করার মতো কোনও কার্যকর উপায় নেই "আর সত্য নয়।

এছাড়াও নোট করুন যে প্রত্যেকে ইন্টারনেটের সাথে 100 এমবিট লিঙ্কে নেই - যেমন মোবাইল এবং স্মার্টফোন; প্রতিটি মেল ক্লায়েন্ট কেবলমাত্র শিরোলেখ ডাউনলোড করতে সক্ষম নয় (যেমন পিওপি 3 এখনও প্রচুর ব্যবহারে রয়েছে), এবং প্রতিটি ব্যবহারকারী প্রতি সপ্তাহে ২০ টি অনিবার্য "এই মজাদার 1 জিবি ভিডিও" ইমেলগুলি ডাউনলোড করতে ইচ্ছুক নয় ( যা প্রদর্শিত হবে ( সিস্টেম তাদের যে পরিমাণ বড় ফাইল দেবে লোকে তাদের পাঠিয়ে দেবে; এবং হ্যাঁ, বেশিরভাগ আইএসপি সহ এফইউপি জাতীয় কিছু রয়েছে)।

টিএল; ডিআর : একটি 1 জিবি ফাইল ই-মেইল করার মতো প্রযুক্তিগতভাবে সম্ভব হওয়া সত্ত্বেও, স্ক্রু ড্রাইভার ব্যবহার করে পেরেকের মধ্যে পাউন্ড করাও প্রযুক্তিগতভাবে সম্ভব হবে - এটি যেমন করা ঠিক তেমন ভাল উপায় নয়, যেমন রয়েছে এই জাতীয় কাজের জন্য আরও উপযুক্ত এমন সরঞ্জামগুলি।


10
+1 এটি একটি খুব খুব ভাল উত্তর :)
এন্টোইন বেনকামাউন

1
100 এমবি লিঙ্ক? যতক্ষণ না আপনি একটি কর্পোরেশন হন, Noone অস্ট্রেলিয়ার 100MB লিঙ্ক এখানে হয়েছে।
ম্যাথু শার্লে

15
টিএলডিআর সংস্করণের জন্য +1 :-)
মনিকা

2
আমার ইমেল ক্লায়েন্ট বেস 64 এ এনকোড করা 1GB ফাইল পছন্দ করবে।
কারাগারে

3
ভাঙা স্থানান্তর পুনরায় শুরু করার কোনও উপায় নেই 1
mr_eclair

32

একই তবে কিছুটা ভিন্ন দৃষ্টিভঙ্গি থেকে:

ইমেলটি বৈদ্যুতিন মেল। আপনি অন্য একটি ছোট কাগজের খামে এই প্রাচীন কাগজ জিনিস হিসাবে মেল জানেন। আপনি এটিতে প্রচুর পাঠ্য লিখতে পারেন তবে 5 বা 6 পৃষ্ঠার বেশি নয়। এবং ইমেল একই কিন্তু বৈদ্যুতিন। এটি পাঠ্যের জন্য ডিজাইন করা হয়েছে (টাইপরাইটারের মতো সাধারণ পাঠ্য)। তারপরে একটি মাইম এক্সটেনশান ছিল যেখানে আপনি এই অভিনব লাল-জ্বলজ্বল এইচটিএমএল মেলগুলি প্রেরণ করতে পারেন।

বিশ্বের কেউই অভিযোগ করবে না এবং বলবে না "ওহ মেলটি এভাবে ১৩২২ খ্রিস্টাব্দে আটকা পড়েছিল। কেন আমি কাগজের খামে একটি হাতি পাঠাতে পারি না?" এটা হয় কিভাবে। এই জাতীয় স্টাফের জন্য লোকেরা প্যাকেট বা পরিবহণের ধারক জাতীয় কিছু আবিষ্কার করেছিল। এভাবেই জিনিসপত্র ও হাতি পাঠাতে হয়। এবং ইন্টারনেটের ছেলেরা এফটিপি আবিষ্কার করেছে (ফাইল ট্রান্সফার প্রোটোকল), নাম পেয়েছে?

বাস্তব বিশ্বে এফটিপি-র অনেকগুলি বিকল্প রয়েছে কারণ এফটিপিও একটি প্রাচীন প্রোটোকল যা বড় অসুবিধাগুলি (বেশিরভাগ সুরক্ষায় এবং ফাইল স্থানান্তরের ক্ষেত্রে নয়)। কিন্তু HTTP- র হল না বিকল্প হিসেবে এটি মেটা ডেটা সহ কেন্দ্রীভূত ডকুমেন্ট সংগ্রহের জন্য উন্নত ছিল। আপনি যে ফাইলগুলি ডাউনলোড এবং আপলোড করতে পারবেন তা এটির জন্য একটি নির্মম প্রসার।

সুতরাং পাঠানোর জন্য একটি চিঠি এবং পণ্য পাঠাতে একটি প্যাকেট ব্যবহার করুন; তথ্য প্রেরণের জন্য ইমেল এবং ফাইল প্রেরণে ট্রান্সপোর্ট প্রোটোকল ব্যবহার করুন।


সম্পাদনা:

ছবিতে থাকতে আমাকে যোগ করতে হবে: এমনকি আপনি যদি স্থানীয় পোস্ট অফিসকে কাগজের খামে হাতিগুলি গ্রহণ করতে রাজি করেন (এবং অতিরিক্ত ফি প্রদান করেন) তবে হাতির বিতরণ করার জন্য আরও কিছু দল রয়েছে। একজন ডাক্তার আছেন যাকে এটি পরবর্তী পোস্ট অফিসে নিয়ে যেতে হবে এবং সম্ভবত হাতির ফিট করার উপযুক্ত ব্যাগ তার কাছে নেই। তবে সম্ভবত তিনি তা পেয়েছিলেন এবং পরবর্তী পোস্ট অফিসে পৌঁছে দিতে চান যা ঘুরেফিরে বলে: "না আমরা হাতি গ্রহণ করি না "।

তাহলে কি করব? রিয়েল ওয়ার্ল্ডের ভাল মেইলম্যান হাতিটিকে প্রথম পোস্ট অফিসে ফিরিয়ে নিয়ে যেত - পরে প্রেরকের কাছে ফিরে আসে। (বৈদ্যুতিন বিশ্বে এটি একটি খারাপ মেলম্যান হবে কারণ তার উচিত ছিল যে হাতির গুলি করা এবং কেবল মৃত্যুর শংসাপত্র প্রেরকের কাছে ফিরিয়ে দেওয়া)।

এমনকি যদি আপনি প্রাপকের সাথে মুখোমুখি হন এমন হাতিদের গ্রহণ করতে পোস্ট ডেলিভারির শৃঙ্খলে সমস্ত লিঙ্ককে বোঝাতে পারতেন। তিনি বলতে পেরেছিলেন যে তিনি হাতিটি চান তবে একটি হাতির মানানসই লেটারবক্স খুব ছোট। (হাতির প্রেরকের লেটারবক্সে ফিট না হলে কী হয় তা উল্লেখ করার দরকার নেই ...)


18
এস উপর ! যতক্ষণ Content-Type: application/x-pachydermশিরোনাম রয়েছে ততক্ষণ , এইচটিটিপি হাতির সংক্রমণে পুরোপুরি সক্ষম;) ভাল পয়েন্টগুলি, যদিও আমার পছন্দের প্রোটোকলটি হবে rsync- যুক্তিসঙ্গতভাবে ভাল উপলব্ধ, সংকোচনের অনুমতি দেয়, ডেল্টা সিঙ্কগুলি, অবিরত স্থানান্তর, এবং এসএসএইচের সাথে ভাল কাজ করে (লেখার জন্য + জোড়া লাগানো).
পিসকভোর

1
এমনকি একটি পি 2 পি পদ্ধতিও যুক্তিসঙ্গত। এটি দর্শকদের উপর নির্ভর করে। ইমেলের মাধ্যমে একটি ফাইলকে বহুবিধ্বস্ত করা প্রত্যেকের এলার্ম বেল বাজানো উচিত। এবং যেমনটি আপনি অন্য কথায় বলেছেন যে কোনও একটি এই পদ্ধতির অনুসরণ করা উচিত নয়: "আপনার যদি কেবল হাতুড়ি থাকে তবে প্রতিটি সমস্যা পেরেকের মতো দেখায়"।
মেলকিউ

হুঁ, হ্যাঁ - একাধিক উদ্দেশ্যপ্রাপ্ত প্রাপকদের জন্য, যেমন টরেন্টগুলি প্রচুর অর্থ দেয়; তবে আমার অভিজ্ঞতায়, আপনার এখনও সেই সমস্ত ব্যবহারকারীদের জন্য (এফটিপি? এইচটিটিপি?) ফ্যালব্যাকের প্রয়োজন যারা এই সমস্ত নতুনফাঙ্গল ট্রান্সফার প্রোটোকল সম্পর্কে সচেতন নন। দর্শকের উপর নির্ভর করে, যেমনটি আপনি বলেছেন।
পিসকভোর

17

এক্সচেঞ্জ 2007 এর সাথে এমন পরিস্থিতিতে পড়ে যেখানে পরিচালন "ইমেলের আকারের কোনও সীমাবদ্ধতা" দর্শনে সাবস্ক্রাইব করে না:

কোনও অভ্যন্তরীণ ব্যবহারকারী তাদের হটমেইল ঠিকানায় একটি সংগীত সিডির আইসো সহ একটি বার্তা প্রেরণ করেছিলেন। বার্তা প্রক্রিয়াকরণের সময় একটি ট্রান্সপোর্ট সার্ভারে কাতারে প্রবেশ করে, পিছনে চাপ চাপিয়ে দেয়, বার্তা জমা দেওয়া বন্ধ করে দেয়। এরপরে ব্যবহারকারীর দৃষ্টিভঙ্গি কর্তব্য করে অন্য পরিবহন সার্ভারে বার্তাটি জমা দিয়েছিল যা কাজ করে যাচ্ছিল; পিছনে চাপ, কোনও বার্তা জমা নেই।

উভয় পরিবহন সার্ভার বার্তায় দম বন্ধ হয়ে গেলে, সমস্ত আউটবাউন্ড ইমেল প্রায় 90 সেকেন্ডের জন্য বন্ধ হয়ে যায়। হটমেইল অবশ্যই বার্তাটি প্রত্যাখ্যান করেছে। খুব শীঘ্রই জায়গায় একটি আকারের সীমা ছিল।


90 এর দশকের মাঝে আমি একটি 20 এমবি ইমেল পেয়েছি। ইমেলটি আসলে আমার মেলবক্সে পৌঁছে দেওয়া হয়েছিল, তবে সার্ভারটি একটি 4.5.1 মাপের ত্রুটি পাঠিয়েছে। এই মুহুর্তে প্রেরণকারী সার্ভার বার্তাটি বার বার করে। এমন একটি লুপ তৈরি করা যা আমার মেইলবক্স বা আমাদের সার্ভারটি পূর্ণ না হওয়া পর্যন্ত পুনরাবৃত্তি করতে থাকে এবং কাতার থেকে মেলটি সরিয়ে অ্যাডমিন দ্বারা ম্যানুয়ালি ঠিক করতে হয়েছিল।
ইএমবি

5

এখানে অন্য মতামত:

যেহেতু কোনও ইমেল সেই পথে একাধিক ইভেন্টে সঞ্চিত রয়েছে, তাই 1 জিবি ফাইল পাঠানো পুরো পথে বেশ কয়েকবার ব্যবহৃত হবে।

এটি সাধারণত "পাঠানো আইটেমগুলিতে" আপনার ক্লায়েন্টের একটি অনুলিপি হতে পারে এবং আইএমএপি ব্যবহার করে সার্ভারে একটি অনুলিপিও প্রদর্শিত হতে পারে (আপনার অ্যাকাউন্টে)।

তারপরে রিসিভিং এন্ড একটি কপি (সার্ভার) রাখবে, সাথে সাথে গ্রাহক প্রান্তে স্থানীয় ক্লায়েন্টের কাছে রাখবে। যদি IMAP ব্যবহার করে থাকেন তবে তা সার্ভারে মুছে ফেলা হবে না (আবার একবার)।

এটি একটি একক 1 জিবি ফাইলের জন্য মোট 4 জিবি। অবশ্যই, আপনি এটিকে ব্যাকআপ হিসাবে বিবেচনা করতে পারেন, তবে এর জন্য আরও ভাল বিকল্প রয়েছে। সার্ভারে ঘটে যেতে পারে এমন অল্পতা উল্লেখ না করা কারণ ব্যবহারকারীদের মেলবক্সগুলি অনির্দিষ্টকালের জন্য বেড়ে যায়।

এবং আমি ঠিক বুঝতে পেরেছি যে যদি ফাইলটি বেস 64 এনকোড করা থাকে তবে এটি আরও বড় হবে (আমার ধারণা প্রায় 33% বড়)।


4

পিসকভরের উত্তর পরিপূরক হিসাবে।

হ্যাঁ, "প্রধান ইমেল প্ল্যাটফর্মগুলি" তাদের পা টেনে নিচ্ছে। তারা প্রোটোকল (এসএমটিপি) ব্যবহার করে এটি করেন যা আজকের মানগুলি (বহু উপায়ে) আপ নয় using

আজকের বিশ্বে, আমরা সহজেই এসএমটিপি প্রতিস্থাপনের জন্য একটি প্রোটোকল ডিজাইন করতে পারি যা বর্তমান সংযুক্তি সমস্যার সমাধান করবে।

সমস্যাটি হ'ল বিশ্বটিকে এতে স্যুইচ করতে হবে।



-2

উল্লিখিত সমস্যাটি হ'ল মূলত ডেটা সংরক্ষণ এবং সংক্রমণ সম্পর্কিত লজিস্টিক সমস্যাগুলি the আধুনিক ক্লাউড বিমূর্তকরণে কোনও ফাইলের আর শারীরিক হওয়া দরকার না - একটি ফাইল-হ্যান্ডেল বিমূর্তি বিভিন্ন স্টোরেজ পদ্ধতিতে আবৃত করতে ব্যবহৃত হতে পারে (যেমন স্থানীয় ডিস্ক, এফটিপিপি) , এইচটিপি, টরেন্ট, ইউটিউব, ক্লাউড স্টোরেজ, ডারনেট, সংযুক্তি, খচ্চর, বিতরণকৃত এফ, অংশ, পুনর্বিবেচনা) - এটি কোনও নতুন ধারণা নয়, এটি পুরোপুরি এখানে বা এক টুকরোতে এখনও নেই। কখন বা যদি এটি আসে, আপনার মেল সংযুক্তিটি কেবল একটি ফাইল পয়েন্টার যা সরাসরি ব্যবহার করা যেতে পারে(যেমন। টরেন্ট ফাইল বা কোনও লিঙ্ক নয়) ভিডিও প্লেয়ার বা যে কোনও সফ্টওয়্যার দ্বারা। বিষয়বস্তু ডাউনলোড বা স্টোরেজটির আসল হ্যান্ডলিং স্বচ্ছভাবে ঘটবে, বিষয়বস্তু আংশিকভাবে একাধিক উত্স থেকে যৌথভাবে-পুনরুদ্ধারযোগ্য ম্যানিফেস্টে সংজ্ঞায়িত হতে পারে (যেমন .torrent ফাইলের মতো তবে সর্বজনস্বীকৃত, এবং পুনরায় পরিবর্তনযোগ্য উপলভ্যতা এবং স্থানীয়তার সীমাবদ্ধতা সহ); প্রকৃত ডাউনলোড এবং স্টোরেজ / ক্যাশিং প্রায়শই আংশিক হতে পারে, কোন অংশটি দেখা হয়েছে তার উপর নির্ভর করে এবং আপনি যদি সামগ্রীটি অ্যাক্সেস করতে বিরতও হন - তাই আপনার শাশুড়ির বিশাল সংযুক্তি আপনার ঘরে ঘরে ব্যান্ডউইথের কোনও অংশই খাবে না depending আপনি যদি তার ইমেলের ভক্ত না হন। স্থায়ীত্ব বা প্রাপ্যতার জন্য, সম্ভবত আপনি '


2
আমি "মেঘ" পরিভাষাটিকে যতটা ঘৃণা করি, আপনার বিবরণ অর্ধেক সত্য; তবে এখনও স্থানান্তর প্রয়োজনীয়তা (ব্যান্ডউইথ) আছে, স্টোরেজ এমনকি যদি এটি কেবলমাত্র মধ্যবর্তী হয়, এবং "স্থানীয়" সার্ভারে উপস্থিতির অভাবের কারণে উল্লেখযোগ্য বিলম্ব প্ররোচিত হতে পারে। এমনকি ফাইলটি প্রাপক দ্বারা অ্যাক্সেস না করা সত্ত্বেও মূল প্রেরককে এখনও পুরো ফাইলটি "মেঘের কাছে" প্রেরণ করতে হবে, "ক্লাউড" পুরো ফাইলটি ধরে রাখতে হবে (সম্ভবত অনির্দিষ্টকালের জন্য), এবং কাঠামোগুলি এই সমস্ত যোগাযোগের জন্য করবে জায়গায় রাখা আছে। আমরা যদি হুইলটিকে নতুন করে দিই, তবে এর চেয়ে ভাল এটি করা যেতে পারে।
ক্রিস এস

1
"আমার ফাইলগুলি আর শারীরিক হওয়ার দরকার নেই" - আমি আমার ডিস্কগুলি থেকে মুক্তি পাওয়ার পরে ধরে রাখি, কারণ তাদের আর সেই আধ্যাত্মিক ফাইলগুলির প্রয়োজন নেই ;) আপনার কাছে স্টোর এবং ট্রান্সফারটি বিমূর্ত করা যেতে পারে এটির একটি ভাল বক্তব্য রয়েছে) , তবে এগুলি বিমূর্ততার দ্বারা কেবল কোথাও লুকিয়ে রয়েছে , যায়নি। আপনি একটি প্রয়োজন চাই সত্যিই ফাইল অ্যাক্সেস লেটেন্সি উপশম চর্বি নল - মিনিটের জন্য যেমন বাজানো একটি HD ভিডিও শুরু, মধ্যম করার চেষ্টা, অলসভাবে ঘোরানো ফেরানো আপনার অঙ্গুষ্ঠ যখন অনুরোধ করা তথ্য (যেমন স্থানীয় সংগ্রহস্থল জন্য নিছক মিলিসেকেন্ড থেকে ভিন্ন) আপনাকে প্রবাহিত হয় । এবং প্রতি একফুট ন্যানোসেকেন্ড আলোর পেস্কি গতিও রয়েছে।
পিসকভোর

সত্য - যদি লোকালতা বা প্রাপ্যতাটি সংজ্ঞাযুক্ত বা কার্যকরভাবে প্রয়োগ না করা হয় তবে এগুলি বেশ ধীরে ধীরে পেতে পারে। কিন্তু ব্যবহারকারী তাদের সংজ্ঞায়িত করে এবং গতি, ব্যান্ডউইথ, প্রাপ্যতা, ইত্যাদি জাতীয় প্রিপেইকড নীতি, ফিল্টার বিধি, বৈশিষ্ট্য, ট্যাগ, ইনফারেন্সিং বিধি ব্যবহার করে বিভিন্ন বাণিজ্য-অফের জন্য কিছুটা দায় নেবে। আমি যখন সংযুক্তি সহ কোনও ইমেল প্রেরণ করি তখন আমার সেগুলি 'আপলোড' করতে হবে না, কারণ তথ্যটি সহজভাবে রিসিভারের জন্য উপলব্ধ করা হয়, তারপরে ডেটা দুটি পক্ষের আচরণের ভিত্তিতে ডিস্ক এবং / অথবা ক্লাউড স্টোরেজে নিজেকে নকল করে বা প্রতিলিপি করে দেয় 'স্টোরেজ ম্যানেজার' ব্যবহারকারী-কনফিগার করা অনুমিত নিয়ম।
আলিফ খেলনা

"ব্যবহারকারী তাদের সংজ্ঞা দেয় এবং কিছুটা দায়িত্ব নিতে পারে" - আপনাকে অবশ্যই একজন পরিচালক হতে হবে।
ক্রিস এস

ম্যানেজার নয় বরং আরও খারাপ কিছু - একটি ভাঙা ফিউচারিস্ট
আলিফ টয়
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.