اگر میں ایک بڑی فائل اپ لوڈ کروں اور عارضی ڈاؤن لوڈ لنک بناؤں تو کیا ہوگا؟

5GB ویڈیو فائل بھیجنا آسان معلوم ہو سکتا ہے۔ فائل کو منتخب کریں، اپ لوڈ پر کلک کریں، پروگریس بار کے مکمل ہونے کا انتظار کریں، پھر لنک کو دوسروں کے ساتھ شیئر کریں۔ لیکن جب فائل اپ لوڈ ہو رہی ہے، پس منظر میں کئی چیزیں ہوتی ہیں۔

فائلوں کو نیٹ ورک پر سفر کرنا، سرور تک پہنچنا، اور اس سے پہلے کہ کوئی اور ان کو ڈاؤن لوڈ کر سکتا ہے، کہیں محفوظ ہونا چاہیے۔ سروس کو یہ بھی یقینی بنانا چاہیے کہ وصول کنندہ بھیجنے والے کے اکاؤنٹ تک رسائی کے بغیر فائلوں تک رسائی حاصل کر سکتا ہے۔ اگر اپ لوڈ کے دوران آپ کا انٹرنیٹ کنکشن ختم ہو جاتا ہے، تو آپ کو پوری فائل کو دوبارہ منتقل کیے بغیر جاری رکھنے کا طریقہ درکار ہے۔

فائل ٹرانسفر سروس HTTP درخواستوں، سٹوریج سسٹمز، ڈیٹا بیس، انکرپشن، اور بیک گراؤنڈ پروسیسز کا استعمال کرتے ہوئے ان کاموں کا انتظام کرتی ہے۔ لیکن ویب سائٹس دراصل ان فائلوں کو کیسے ہینڈل کرتی ہیں جن کا سائز کئی گیگا بائٹس ہے؟ ایک درخواست میں سب کچھ اپ لوڈ کریں؟ اپ لوڈ مکمل ہونے کے بعد فائلیں کہاں جاتی ہیں؟ ڈاؤن لوڈ لنک کی میعاد ختم ہونے پر کیا ہوتا ہے؟

اس آرٹیکل میں، ہم دیکھیں گے کہ فائل ٹرانسفر سروسز کس طرح بڑے اپ لوڈز کو ہینڈل کرتی ہیں، فائلز کو اسٹور کرتی ہیں، ڈاؤن لوڈ لنکس جنریٹ کرتی ہیں، اور گرے ہوئے کنکشنز اور میعاد ختم ہونے والے ٹرانسفرز کا نظم کرتی ہیں۔ پھر، ایک بار جب آپ اس تھیوری کو سمجھ لیں کہ یہ سب کیسے کام کرتا ہے، تو آئیے Node.js کا استعمال کرتے ہوئے ایک بنیادی حصہ فائل اپ لوڈر بنا کر ان میں سے کچھ عمل کو عملی شکل میں دیکھتے ہیں۔

ہم کیا احاطہ کریں گے:

ای میل منسلکات کیوں ناکام ہو جاتے ہیں: SMTP بڑی فائلوں کے لیے ڈیزائن نہیں کیا گیا ہے۔

اس سے پہلے کہ ہم مخصوص فائل ٹرانسفر سروسز کو دیکھیں، یہ سمجھنے میں مدد کرتا ہے کہ آپ بڑی فائلوں کو ای میلز کے ساتھ کیوں منسلک نہیں کر سکتے۔ ای میل کے ذریعے بڑی فائلیں بھیجنا بنیادی طور پر ناقص ہے کیونکہ بنیادی فن تعمیر متن کے لیے بنایا گیا ہے، نہ کہ ہائی ریزولوشن میڈیا کے لیے۔

SMTP اور منسلکہ سائز کی حد

سادہ میل ٹرانسفر پروٹوکول (SMTP) انٹرنیٹ پر ای میل پیغامات کی ترسیل کو سنبھالتا ہے۔ چونکہ سرورز کے پاس محدود بینڈوتھ اور اسٹوریج کی جگہ ہوتی ہے، اس لیے ای میل فراہم کرنے والے سخت منسلکہ سائز کی حدیں لگاتے ہیں، عام طور پر تقریباً 25MB۔ تاہم، یہ حد انکوڈ شدہ پیغام کے سائز کے ساتھ ساتھ آپ کی ہارڈ ڈرائیو پر اصل فائل پر بھی لاگو ہوتی ہے۔

بیس 64 کا مسئلہ

ای میل منسلکات کو عام طور پر MIME اور Base64 فارمیٹس کا استعمال کرتے ہوئے انکوڈ کیا جاتا ہے۔ Base64 ضروری ہے کیونکہ یہ بائنری ڈیٹا کو متن کے موافق حروف میں تبدیل کرتا ہے جسے ای میل سرور محفوظ طریقے سے روٹ کر سکتے ہیں۔ یہ ٹرانسمیشن کے مسئلے کو حل کرتا ہے، لیکن بہت زیادہ کارکردگی کے مسائل پیدا کرتا ہے. یہ انکوڈنگ ڈیٹا کے سائز میں تقریباً 33 فیصد اضافہ کرتی ہے۔

آپ اس کے لیے بنیادی تفصیلات یہاں پڑھ سکتے ہیں: آر ایف سی 2045MIME کے لیے Base64 ٹرانسفر انکوڈنگ کی وضاحت کرتا ہے۔ عملی طور پر، اس کا مطلب ہے کہ ایک 30MB ویڈیو فائل کے لیے تقریباً 40MB جگہ کی ضرورت ہوگی اس سے پہلے کہ اضافی پیغام کے اوور ہیڈ کا حساب لگایا جائے، جو زیادہ تر ای میل سرورز پر اچھالنے کی ضمانت ہے۔

بنیادی فن تعمیر: فائل ٹرانسفر سروس کے پیچھے کیا ہوتا ہے؟

ای میل کی حدود کو روکنے کے لیے، فائل ٹرانسفر سروسز ایک خاص، ڈیکپلڈ فن تعمیر کا استعمال کرتی ہیں۔ خود ان میں سے کئی سسٹمز بنانے کے بعد، میں سمجھتا ہوں کہ ڈیٹا کے بہاؤ کو سمجھنے کے لیے، پانچ اہم اجزاء کا واضح ذہنی ماڈل قائم کرنا ضروری ہے۔

کلائنٹ

سفر کلائنٹ سے شروع ہوتا ہے، عام طور پر ایک ویب براؤزر یا ڈیسک ٹاپ ایپلیکیشن جہاں بھیجنے والا فائل منتخب کرتا ہے۔ جدید براؤزر فائل میٹا ڈیٹا تک رسائی حاصل کرنے، خام مواد کو پڑھنے، اور ڈیٹا کے نیٹ ورک تک پہنچنے سے پہلے فائلوں کو ذہانت سے چھوٹے، زیادہ قابل انتظام حصوں میں تقسیم کرنے کے لیے JavaScript کے فائل API کا استعمال کرتے ہیں۔

اپ لوڈ سرور

جب کلائنٹ ڈیٹا کی منتقلی شروع کرتا ہے، اپ لوڈ سرور مداخلت کرتا ہے۔ یہ سرور اپ لوڈ کی درخواستیں وصول کرتا ہے، صارفین کی تصدیق کرتا ہے، آنے والے ڈیٹا کی توثیق کرتا ہے، اور اپ لوڈ کے پورے عمل کو مربوط کرتا ہے۔ یہ ٹریفک پولیس اہلکار کے طور پر کام کرتا ہے، اس بات کو یقینی بناتا ہے کہ ڈیٹا کا کچھ حصہ صحیح فارمیٹ میں پہنچ جائے۔

اسٹوریج کی سطح

روایتی ایپلیکیشن سرورز بڑی فائلوں کو رکھنے میں خوفناک ہیں، لہذا اسٹوریج کی تہہ ہیوی لفٹنگ کرتی ہے۔ اپ لوڈ کردہ فائلوں کو عام طور پر براہ راست کسی آبجیکٹ اسٹوریج سلوشن پر بھیج دیا جاتا ہے۔ یہ سسٹم کو بنیادی اپ لوڈ سرور کو کریش کیے بغیر غیر معینہ مدت تک پیمانہ کرنے کی اجازت دیتا ہے۔

میٹا ڈیٹا ڈیٹا بیس

جبکہ اصل فائل کو آبجیکٹ اسٹوریج میں منتقل کیا جا رہا ہے، ایپلیکیشن کو یہ یاد رکھنے کے لیے ایک طریقہ درکار ہے کہ وہ فائل کیا ہے۔ میٹا ڈیٹا ڈیٹا بیس اہم معلومات کو محفوظ کرتا ہے جس میں اصل فائل کا نام، فائل کا سائز، مواد کی قسم، مخصوص آبجیکٹ اسٹوریج کلید، منفرد ٹرانسفر شناخت کنندہ، اور درست میعاد ختم ہونے کا ٹائم اسٹیمپ شامل ہے۔

ڈاؤن لوڈ سرور

جب کوئی مشترکہ لنک کو کھولتا ہے، تو ڈاؤن لوڈ سرور اپنے قبضے میں لے لیتا ہے۔ یہ اجازتوں اور میعاد ختم ہونے کی تاریخوں کو چیک کرنے کے لیے ڈیٹا بیس کی جانچ پڑتال کرتا ہے، اور اگر سب کچھ درست ہے، تو یہ ذخیرہ شدہ چیز کو سٹوریج کی پرت سے بازیافت کرتا ہے اور اسے پاس کرتا ہے۔

چنکنگ اور دوبارہ شروع کرنے کے قابل اپ لوڈز: کتنی بڑی فائلیں خراب انٹرنیٹ کنیکشن سے بچ جاتی ہیں۔

ایک مستقل نیٹ ورک کی درخواست میں 5GB فائل کو منتقل کرنا ایک تباہی ہے جس کا انتظار کیا جا رہا ہے۔ اگر کنیکٹیویٹی 99% تک گر جاتی ہے تو، واحد درخواست کا فن تعمیر صارف کو ہر چیز کو دوبارہ شروع کرنے پر مجبور کرتا ہے۔

بڑی فائلوں کو چھوٹے ٹکڑوں میں تقسیم کریں۔

اس مسئلے کو حل کرنے کے لیے، جدید کلائنٹس بڑی فائلوں کو چھوٹے حصوں میں تقسیم کرتے ہیں، جیسے کہ 10MB ٹکڑوں میں۔ ہر حصہ سرور پر ایک آزاد HTTP درخواست کے طور پر اپ لوڈ کیا جاتا ہے۔ سرور احتیاط سے ٹریک کرتا ہے کہ کون سے ٹکڑے آئے ہیں۔ کچھ جدید سسٹمز متوازی طور پر ایک ساتھ متعدد ٹکڑوں کو بھی اپ لوڈ کر سکتے ہیں، جس سے مجموعی تاخیر کو نمایاں طور پر کم کیا جا سکتا ہے۔

یہ نوٹ کرنا ضروری ہے کہ چنکڈ اپ لوڈ HTTP chunked ٹرانسفر انکوڈنگ (HTTP میسج باڈی کو فریم کرنے کا ایک طریقہ کار) سے بالکل مختلف آرکیٹیکچرل پیٹرن ہے۔

اگر میرا انٹرنیٹ کنکشن کھو جائے تو کیا ہوگا؟

فرض کریں کہ جب آپ کا Wi-Fi کنکشن تصادفی طور پر گرا تو آپ کی 80% بڑی فائلیں کامیابی کے ساتھ اپ لوڈ ہو گئیں۔ اگر دوبارہ شروع کرنے کے قابل اپ لوڈز نہیں ہیں تو آپ کی پیشرفت ضائع ہو جائے گی۔ دوبارہ شروع کرنے کے قابل فن تعمیر کے ساتھ، کلائنٹ دوبارہ جوڑتا ہے اور سرور سے اپ لوڈ آفسیٹ اور کامیابی کے ساتھ موصول اور ذخیرہ شدہ بائٹس کی صحیح تعداد کے لیے پوچھتا ہے۔ اس کے بعد کلائنٹ صحیح جگہ سے بغیر کسی رکاوٹ کے اپ لوڈ کرنا جاری رکھتا ہے۔

چیکسم: تصدیق کریں کہ یہ خراب نہیں ہے۔

نیٹ ورک کی منتقلی بعض اوقات بٹس کو پلٹ سکتی ہے، جس کی وجہ سے فائلیں خراب ہو جاتی ہیں۔ اس کو روکنے کے لیے، کلائنٹ بھیجنے سے پہلے ہر ایک حصہ کے لیے ایک کرپٹوگرافک ہیش (چیکسم) تیار کرتا ہے۔ سرور حصہ وصول کرتا ہے، اپنی ہیش کا حساب لگاتا ہے، اور دونوں کا موازنہ کرتا ہے۔ اگر چیکسم مماثل نہیں ہوتے ہیں، تو سرور حصہ کو مسترد کر دیتا ہے اور کلائنٹ سے دوبارہ کوشش کرنے کو کہتا ہے۔

اگر آپ اس پر عمل درآمد کرنا چاہتے ہیں۔ TUS دوبارہ شروع کرنے کے قابل اپ لوڈ پروٹوکول اپ لوڈ آفسیٹس اور چیکسم تصدیق کے انتظام کے لیے ایک لاجواب، معیاری حوالہ۔ بھی، ایمیزون S3 ملٹی پارٹ اپ لوڈ گائیڈ متوازی منتقلی پر کارروائی کرنے اور ناکام حصوں کی دوبارہ کوشش کرنے کے لیے انڈسٹری کے معیاری بلیو پرنٹ فراہم کرتا ہے۔

محفوظ کریں اور لنکس بنائیں: آپ کی فائلیں دراصل کہاں جاتی ہیں؟

ایک بار جب تمام ٹکڑوں کی شناخت اور دوبارہ جمع ہو جائے تو، سروس کو فائلوں کو ذخیرہ کرنے کے لیے ایک محفوظ جگہ کی ضرورت ہوتی ہے جب تک کہ وصول کنندہ انہیں ڈاؤن لوڈ کرنے کے لیے تیار نہ ہو۔

سروسز آبجیکٹ اسٹوریج کیوں استعمال کرتی ہیں۔

میری رائے میں، موجودہ لوکل سرور ڈائرکٹری میں گیگا بائٹس صارف کے اپ لوڈز کو ذخیرہ کرنے کی کوشش کرنا ایک تعمیراتی غلطی ہے۔ اس کے بجائے، سروس آبجیکٹ اسٹوریج پر انحصار کرتی ہے۔ فائلیں باقاعدہ آبجیکٹ کے طور پر محفوظ کی جاتی ہیں، اور ہر آبجیکٹ کو ایک منفرد کلید تفویض کی جاتی ہے۔ آبجیکٹ اسٹوریج انتہائی پائیدار ہے اور بیک وقت لاکھوں بڑی فائلوں کو ایڈجسٹ کرنے کے لیے بہت آسانی سے پیمانہ ہے۔

ڈاؤن لوڈ لنکس کیسے بنائے جاتے ہیں۔

ذخیرہ شدہ فائلوں اور قابل اشتراک لنکس کے درمیان تعلق میٹا ڈیٹا ڈیٹا بیس پر منحصر ہے۔ اپ لوڈ مکمل ہونے کے بعد، ایپلیکیشن فائل کی سٹوریج کی کو ڈیٹا بیس میں اسٹور کرتی ہے اور ایک منفرد رسائی ٹوکن تیار کرتی ہے۔ وصول کنندہ کو ایک URL موصول ہوتا ہے جس میں وہ مخصوص ٹوکن ہوتا ہے۔ جب آپ کسی لنک پر کلک کرتے ہیں، تو سرور ٹوکن کو پڑھتا ہے، اس کے ڈیٹا بیس میں متعلقہ فائل تلاش کرتا ہے، اور آپ کی ڈاؤن لوڈ کی اجازتوں کو چیک کرتا ہے۔

ان لنکس کا اندازہ لگانا اتنا مشکل کیوں ہے؟

محفوظ فائل ٹرانسفر لنکس اعلی درجے کی اینٹروپی پر بہت زیادہ انحصار کرتے ہیں۔ یہ وہ بے ترتیب پن ہے جس کی وجہ سے ٹوکنز کی ریاضی کی پیش گوئی کرنا تقریباً ناممکن ہو جاتا ہے۔ مزید برآں، سیکورٹی سسٹمز دستخط شدہ یو آر ایل استعمال کرتے ہیں۔ یہ ایک ایسا یو آر ایل ہے جس میں ایک کرپٹوگرافک دستخط ہے جو محدود اور سختی سے نافذ شدہ مدت کے لیے رسائی کی اجازت دیتا ہے۔

جیسا کہ میں بیان کیا گیا ہے۔ OWASP سیشن مینجمنٹ چیٹ شیٹمناسب رسائی کنٹرول، میعاد ختم ہونے کی پالیسیوں، اور ٹوکن لیک تحفظ کے بغیر، غیر مطلوبہ لنکس خود بخود محفوظ نہیں ہوتے ہیں۔

میعاد ختم ہونا اور صفائی: جب منتقلی کی میعاد ختم ہو جاتی ہے تو کیا ہوتا ہے؟

فائل ٹرانسفر سروسز ڈیٹا کے پیٹا بائٹس کو ہینڈل کرتی ہیں، اس لیے وہ اپ لوڈ کردہ فائلوں کو دیوالیہ ہوئے بغیر ہمیشہ کے لیے اسٹور نہیں کر سکتیں۔ وہ جارحانہ لائف سائیکل مینجمنٹ پر انحصار کرتے ہیں۔

ٹی ٹی ایل (لائف ٹائم)

ہر منتقلی کو ٹائم ٹو لائیو (TTL) یا میعاد ختم ہونے کا ٹائم اسٹیمپ تفویض کیا جاتا ہے۔ اس وقت کے بعد، ڈیٹا بیس فوری طور پر منتقلی کے شناخت کنندہ کو باطل کر دے گا تاکہ ڈاؤن لوڈ لنک مزید رسائی کی اجازت نہ دے۔

خودکار صفائی کے کام

چونکہ لنک کی میعاد ختم ہونا اور جسمانی حذف ہونا ضروری نہیں ہے کہ بیک گراؤنڈ ورکر یا شیڈول کرون جاب اصل صفائی کو سنبھالتا ہے۔ یہ کارکن وقتاً فوقتاً ڈیٹا بیس کو اسکین کرتے ہیں تاکہ میعاد ختم ہونے والی منتقلیوں کو تلاش کیا جا سکے، انہیں مستقل طور پر غیر دستیاب کے طور پر نشان زد کریں، سٹوریج کی تہہ سے ملٹی گیگا بائٹ سائز والی اشیاء کو حذف کر دیں، اور آخر میں پرانے میٹا ڈیٹا کو ہٹا دیں۔

ڈاؤن لوڈ کی حد

کچھ خدمات اس تعداد کو محدود کر سکتی ہیں جب بھیجنے والا فائل ڈاؤن لوڈ کر سکتا ہے۔ ایک بار جب ڈاؤن لوڈز کی تعداد ایک حد تک پہنچ جاتی ہے، تو لنک بالکل ایسا برتاؤ کرتا ہے جیسے TTL کی میعاد ختم ہو گئی ہو، غیر مجاز تقسیم کو کنٹرول کرنے کا ایک بہترین طریقہ فراہم کرتا ہے۔

حفاظتی پرت: ٹرانزٹ اور آرام میں فائلوں کی حفاظت کرتا ہے۔

فائل ٹرانسفر سیکیورٹی کبھی بھی ایک جادوئی خصوصیت کے بارے میں نہیں ہے۔ آپ کے ڈیٹا کو روکے جانے یا چوری ہونے سے بچانے کے لیے دفاع کی متعدد پرتوں کی ضرورت ہوتی ہے۔

ٹرانزٹ میں TLS خفیہ کاری

ڈیٹا کو مکمل طور پر انکرپٹ کیا جاتا ہے کیونکہ یہ بھیجنے والے، ڈیلیوری سروس اور وصول کنندہ کے درمیان منتقل ہوتا ہے۔ جدید پلیٹ فارمز HTTPS کا استعمال کرتے ہیں، جو سخت TLS پروٹوکول کے ذریعے تعاون یافتہ ہے، اس بات کو یقینی بناتے ہوئے کہ کوئی بھی ڈیٹا پیکٹ کے درمیانی راستے پر نہیں جا سکتا۔

اس بارے میں مزید جاننے کے لیے کہ انٹرپرائز کی سطح پر اس کی تشکیل کیسے کی جاتی ہے، NIST SP 800-52 نظرثانی 2 TLS کو لاگو کرنے کے بارے میں مکمل رہنمائی فراہم کرتا ہے۔

باقی میں خفیہ کاری

ایک بار جب فائلیں سٹوریج کی پرت پر پہنچ جاتی ہیں، تو آرام سے انکرپشن یقینی بناتی ہے کہ یہاں تک کہ اگر کوئی بدنیتی پر مبنی اداکار جسمانی طور پر سرور ہارڈویئر تک رسائی حاصل کر لیتا ہے، تو انہیں صرف ناقابل پڑھا ہوا، گڑبڑ ڈیٹا ملے گا۔ یہ نوٹ کرنا ضروری ہے کہ باقی میں خفیہ کاری اینڈ ٹو اینڈ انکرپشن جیسی نہیں ہے۔ سروس فراہم کرنے والے اب بھی معیاری ترتیبات کے ساتھ انکرپشن کیز کا نظم کرتے ہیں۔

پاس ورڈ سے محفوظ لنک

غیر مجاز صارفین کو درست URLs تک رسائی سے روکنے کے لیے، بھیجنے والے پاس ورڈ شامل کر سکتے ہیں۔ اس سے ایک ثانوی رسائی کنٹرول پرت بنتی ہے جسے سرور کے آبجیکٹ اسٹوریج سے فائلوں کو بازیافت کرنے کی کوشش کرنے سے پہلے صاف کرنا ضروری ہے۔ اضافی تحفظ کی خصوصیات، جیسے کہ خودکار پاس ورڈ کا اندازہ لگانے کے لیے شرح محدود، اس پرت کی تاثیر کو برقرار رکھتی ہے۔

حقیقی زندگی کی مثال: کس طرح مقبول فائل ٹرانسفر سروسز فائل شیئرنگ کو ہینڈل کرتی ہیں۔

یہ دیکھنا کہ موجودہ کمپنیاں ان تصورات کو کیسے نافذ کرتی ہیں نظریہ اور عمل کے درمیان فرق کو ختم کرنے میں مدد کر سکتی ہیں۔

WeTransfer: عارضی منتقلی اور پاس ورڈ تحفظ

WeTransfer مکمل طور پر عارضی اشتراک کے قابل لنکس کے ارد گرد بنایا گیا ہے۔ منتقلی کی میعاد ختم ہونے کی سخت تاریخیں ہوتی ہیں اور پریمیم صارفین پاس ورڈ کے تحفظ کو نافذ کر سکتے ہیں۔ سیکیورٹی دستاویزات کے مطابق، اس کے سرورز پر موجود فائلیں ٹرانسمیشن کے دوران معیاری TLS انکرپشن اور باقی میں AES-256 انکرپشن کا استعمال کرتے ہوئے محفوظ ہیں۔

ڈراپ باکس ٹرانسفر: بغیر تعاون کے فائلیں بھیجیں۔

معیاری مشترکہ فولڈرز کے برعکس، ڈراپ باکس ٹرانسفر اسٹینڈ تنہا ڈاؤن لوڈ کے قابل لنکس بناتا ہے۔ وصول کنندگان کو پے لوڈ ڈاؤن لوڈ کرنے کے لیے ڈراپ باکس اکاؤنٹ کی ضرورت نہیں ہے۔ یہ قابل ترتیب میعاد ختم ہونے کی تاریخوں، پاس ورڈز، اور خودکار ڈاؤن لوڈ کی اطلاعات کا استعمال کرتا ہے، جس میں بھیجنے والے کے مخصوص سبسکرپشن پلان کے ذریعے طے شدہ فائل کے سائز کی زیادہ سے زیادہ حد ہوتی ہے۔

کہیں بھی بھیجیں: براہ راست منتقلی اور عارضی لنکس

کہیں بھی بھیجیں ایک زبردست ہائبرڈ طریقہ اختیار کرتا ہے۔ چھ ہندسوں کی کلید کی منتقلی کا طریقہ کار حقیقی وقت میں 10 منٹ کے اندر ایک وقت کے استعمال کے لیے کام کرتا ہے اور اکثر پیئر ٹو پیئر کنکشن کا استعمال کرتا ہے۔ اس کے برعکس، معیاری مشترکہ لنک آپشن کو سرور پر مبنی فن تعمیر سے بدل دیا گیا ہے جہاں آپ فائلیں اپ لوڈ کرتے ہیں اور لنک کو 48 گھنٹے تک درست رکھتے ہیں۔

فائل میل: بڑے پیمانے پر ڈیلیوری اور میعاد ختم ہونے کا کنٹرول

طاقتور ای میل اور قابل اشتراک لنک ڈیلیوری کے اختیارات کے ساتھ، فائل میل بڑے پے لوڈز کو آسانی سے ہینڈل کرتا ہے۔ یہ انتہائی قابل ترتیب میعاد ختم ہونے کے کنٹرول اور سخت پاس ورڈ تحفظ پیش کرتا ہے۔ مفت سروس ٹائر فی الحال 5GB کی منتقلی کی حد کی اجازت دیتا ہے اور خودکار صفائی شروع ہونے سے پہلے آپ کے ڈیٹا کو 7 دن تک اسٹوریج تک محفوظ رکھتا ہے۔

ہینڈ آن: Node.js کا استعمال کرتے ہوئے ایک کم سے کم حصہ فائل اپ لوڈر بنانا

تھیوری کو سمجھنا بہت اچھا ہے، لیکن اسے خود بنانا ثابت کرتا ہے کہ یہ عملی طور پر کیسے کام کرتا ہے۔ آئیے ایک سادہ ایپلی کیشن بناتے ہیں جو براؤزر میں فائل کو چھوٹے حصوں میں توڑ دیتی ہے، انہیں Node.js سرور پر اپ لوڈ کرتی ہے، اور پھر دوبارہ جڑ جاتی ہے۔

مرحلہ 1: اپنا Node.js پروجیکٹ ترتیب دیں۔

آنے والی فائل کے ٹکڑوں کو پروسیس کرنے کے لیے آپ کو Node.js، ایکسپریس فریم ورک، اور ملٹر کی ضرورت ہوگی۔ بلٹ ان fs ماڈیول فائل آپریشنز کو ہینڈل کرتا ہے۔ پہلے نوڈ پروجیکٹ بنائیں اور مطلوبہ انحصار انسٹال کریں۔

mkdir file-transfer
cd file-transfer
npm init -y
npm install express multer

مرحلہ 2: فائل کو چھوٹے ٹکڑوں میں تقسیم کریں۔

پہلے public اگر ڈائریکٹری پہلے سے موجود نہیں ہے تو اسے اپنے پروجیکٹ فولڈر میں شامل کریں۔ پھر، upload.js اس ڈائریکٹری کے اندر۔ ہم براؤزر کا JavaScript File API اور اس کا API استعمال کریں گے۔ slice() اپنے کمپیوٹر کی RAM میں پورے 5GB پے لوڈ کو لوڈ کیے بغیر فائل کے ایک چھوٹے سے حصے کو پڑھنے کا ایک طریقہ۔

const chunkSize = 5 * 1024 * 1024;

async function uploadFile(file) {
    const totalChunks = Math.ceil(file.size / chunkSize);
    const uploadId = crypto.randomUUID();

    for (let index = 0; index < totalChunks; index++) {
        const chunk = file.slice(
            index * chunkSize,
            (index + 1) * chunkSize
        );

        const formData = new FormData();
        formData.append("chunk", chunk);

        const response = await fetch(
            `/upload/${uploadId}/${index}/${totalChunks}`,
            {
                method: "POST",
                body: formData
            }
        );

        if (!response.ok) {
            throw new Error(`Chunk ${index} failed to upload`);
        }
    }

    const response = await fetch(`/complete/${uploadId}`, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
            totalChunks,
            filename: file.name
        })
    });

    if (!response.ok) {
        throw new Error("File reassembly failed");
    }
}

یہاں، crypto.randomUUID() اپنے اپ لوڈ کے لیے ایک منفرد ID بنائیں۔ براؤزر ہر ایک حصہ کو انفرادی طور پر بھیجتا ہے اور ایک ہی ID کا استعمال کرتے ہوئے تمام ٹکڑوں کو اصل فائل کے ساتھ جوڑتا ہے۔

مرحلہ 3: ایکسپریس میں اپ لوڈ اینڈ پوائنٹ بنائیں

سرور کی طرف (server.js)، ہر ایک حصہ کو وصول کرنے اور عارضی طور پر ذخیرہ کرنے کے لیے ایک اختتامی نقطہ درکار ہے۔ سرور اپ لوڈ ID اور chunk index کا استعمال کرتا ہے اس بات کا تعین کرنے کے لیے کہ ہر ایک حصہ کہاں سے تعلق رکھتا ہے، اور ٹکڑوں کی کل تعداد اپ لوڈ کی توثیق میں مدد کرتی ہے۔ ہم آنے والے ملٹی پارٹ فارم ڈیٹا کو پارس کرنے کے لیے ملٹر کا استعمال کرتے ہیں۔

const express = require("express");
const multer = require("multer");
const fs = require("fs");
const path = require("path");
const { pipeline } = require("stream/promises");

const app = express();

app.use(express.static(path.join(__dirname, "public")));

const chunksDir = path.join(__dirname, "chunks");
const tempDir = path.join(chunksDir, "temp");

fs.mkdirSync(tempDir, { recursive: true });

const upload = multer({
    dest: tempDir,
    limits: { fileSize: 5 * 1024 * 1024 }
});

app.post(
    "/upload/:id/:index/:total",
    upload.single("chunk"),
    async (req, res) => {
        try {
            const { id, index, total } = req.params;

            if (!req.file) {
                return res.status(400).send("No chunk received");
            }

            if (
                !/^[a-f0-9-]{36}$/i.test(id) ||
                !Number.isInteger(Number(index)) ||
                !Number.isInteger(Number(total)) ||
                Number(total) < 1 ||
                Number(total) > 10000 ||
                Number(index) < 0 ||
                Number(index) >= Number(total)
            ) {
                return res.status(400).send("Invalid upload details");
            }

            const folder = path.join(chunksDir, id);

            await fs.promises.mkdir(folder, {
                recursive: true
            });

            await fs.promises.rename(
                req.file.path,
                path.join(folder, `${index}.part`)
            );

            res.send("Chunk received");

        } catch (error) {
            res.status(500).send("Upload failed");
        }
    }
);

سرور ہر ایک ٹکڑے کو ذخیرہ کرنے کے لیے اپ لوڈ ID اور اشاریہ کا استعمال کرتا ہے تاکہ اپ لوڈ مکمل ہونے کے بعد انفرادی حصوں کی شناخت اور بازیافت کی جا سکے۔

مرحلہ 4: اصل فائلوں کو دوبارہ جوڑیں۔

ایک بار جب کلائنٹ اس بات کی تصدیق کرتا ہے کہ تمام ٹکڑوں کو بھیج دیا گیا ہے، حتمی دوبارہ جوڑنے کا راستہ شروع ہو جاتا ہے۔ سرور پہلے فرض کرتا ہے کہ تمام متوقع حصے ہیں۔ chunks/ ڈائریکٹری پھر ٹکڑوں کو ترتیب وار استعمال کرتے ہوئے پڑھیں: fs.createReadStream() اسی آؤٹ پٹ فائل کو استعمال کرتے ہوئے لکھیں: fs.createWriteStream(). پہلا حصہ ایک فائل بناتا ہے اور اس کے بعد کے ٹکڑے فائل میں شامل ہوتے ہیں۔ جب اصل فائلوں کو دوبارہ جمع کیا جاتا ہے، سرور جگہ بنانے کے لیے عارضی ٹکڑوں کو حذف کر دیتا ہے۔

const uploadsDir = path.join(__dirname, "uploads");

fs.mkdirSync(uploadsDir, { recursive: true });

app.use(express.json());

app.post("/complete/:id", async (req, res) => {
    try {
        const { id } = req.params;
        const { totalChunks, filename } = req.body;

        if (
            !/^[a-f0-9-]{36}$/i.test(id) ||
            !Number.isInteger(totalChunks) ||
            totalChunks < 1 ||
            totalChunks > 10000 ||
            typeof filename !== "string"
        ) {
            return res.status(400).send("Invalid upload details");
        }

        const folder = path.join(chunksDir, id);

        for (let i = 0; i < totalChunks; i++) {
            const chunkPath = path.join(folder, `${i}.part`);

            if (!fs.existsSync(chunkPath)) {
                return res.status(400).send(`Missing chunk ${i}`);
            }
        }

        const safeName =
            path.basename(filename).replace(/[^\w.-]/g, "_") ||
            "upload.bin";

        const outputPath = path.join(
            uploadsDir,
            `${id}-${safeName}`
        );

        await fs.promises.rm(outputPath, { force: true });

        for (let i = 0; i < totalChunks; i++) {
            const chunkPath = path.join(folder, `${i}.part`);

            await pipeline(
                fs.createReadStream(chunkPath),
                fs.createWriteStream(outputPath, {
                    flags: i === 0 ? "w" : "a"
                })
            );
        }

        await fs.promises.rm(folder, {
            recursive: true,
            force: true
        });

        res.json({
            message: "File assembled successfully"
        });

    } catch (error) {
        res.status(500).send("Reassembly failed");
    }
});

آخر میں، نیچے درج ذیل کوڈ شامل کریں: server.js ایکسپریس سرور شروع کرنے کے لیے:

app.listen(3000, () => {
    console.log("Server running at http://localhost:3000");
});

مرحلہ 5: ٹیسٹ اپ لوڈ

چلا کر سرور شروع کریں: node server.js آپ کے ٹرمینل میں۔ پھر اسے کھولیں۔ http://localhost:3000 اپنے براؤزر میں درمیانے درجے کی ویڈیو فائل کو منتخب کرکے اپنے اپ لوڈ کی جانچ کریں۔ اپنے براؤزر کا نیٹ ورک ٹیب کھولیں کہ فائلوں کو ٹکڑوں میں کیسے تقسیم کیا جاتا ہے اور ترتیب وار منتقل کیا جاتا ہے۔ آخر میں، اپنے سرور کو چیک کریں: uploads/ ڈائریکٹری اسمبل شدہ فائل کا بائٹ سائز وہی ہونا چاہیے جو اصل اور صحیح طریقے سے کھلا ہو۔

بنانا public/index.html:

    


    
Upload a File

    
    Upload

    

     {
            const file = fileInput.files[0];

            if (!file) {
                status.textContent = "Select a file first.";
                return;
            }

            button.disabled = true;

            try {
                await uploadFile(file);
                status.textContent = "Upload completed!";
            } catch (error) {
                status.textContent = error.message;
            } finally {
                button.disabled = false;
            }
        });
    ]]>

میمو: یہ نفاذ حصہ اپ لوڈ کرنے اور فائل کو دوبارہ جوڑنے کے بنیادی میکانزم کو ظاہر کرتا ہے۔ یہ دوبارہ شروع کرنے کے قابل اپ لوڈز، چیکسم کی تصدیق، تصدیق، آبجیکٹ اسٹوریج، یا عارضی ڈاؤن لوڈ لنکس کو لاگو نہیں کرتا ہے۔

پروڈکشن لیول فائل ٹرانسفر سروسز کے لیے بھی مستقل اپ لوڈ اسٹیٹ، ایکسیس کنٹرول، دوبارہ ہینڈلنگ کی کوشش، سالمیت کی جانچ، اور خودکار صفائی کی ضرورت ہوتی ہے۔

نتیجہ: سادہ لنکس میں بہت ساری انجینئرنگ چھپی ہوئی ہے۔

بڑی فائلیں بھیجنے کے لیے ایک ساتھ کام کرنے کے لیے متعدد عمل درکار ہوتے ہیں۔ براؤزر میں اپ لوڈ پروسیسنگ اور چنک مینجمنٹ سے لے کر آبجیکٹ اسٹوریج، میٹا ڈیٹا ٹریکنگ، انکرپشن، اور خودکار کلین اپ تک، ہر جزو فائل ٹرانسفر آپریشنز میں ایک مخصوص کردار ادا کرتا ہے۔

یہ عمل یہ بھی بتاتے ہیں کہ کس طرح سروس سے باہر اپ لوڈز کو ہینڈل کیا جائے، مشترکہ فائلوں تک رسائی کو کنٹرول کیا جائے، اور منتقلی کی میعاد ختم ہونے پر ڈیٹا کو کیسے ہٹایا جائے۔ یہ سمجھنا کہ یہ اجزاء کیسے مل کر کام کرتے ہیں جب بھی کوئی ایک بڑی فائل اپ لوڈ کرتا ہے اور ڈاؤن لوڈ کا لنک شیئر کرتا ہے تو یہ دیکھنا آسان ہو جائے گا کہ پردے کے پیچھے کیا ہو رہا ہے۔