Original article: https://kermitproject.org/k95.html
کومپیکٹ، تیز، مضبوط، پورٹیبل Kermit فائل ٹرانسفر سورس کوڈ آلات یا C پروگراموں میں سرایت کرنے کے لیے
|
ورژن: 1.8 تاریخ: 27 مئی 2021 اس صفحہ کو آخری بار اپ ڈیٹ کیا گیا: بدھ 24 مئی 16:24:30 2023 |
اوپن سورس کا اعلان: ورژن 1.6 کے ساتھ 30 مارچ 2011 سے موثر، E-Kermit کو نظر ثانی شدہ 3-Clause BSD لائسنس کے تحت "جیسا ہے" جاری کیا گیا ہے ۔
26 مئی 2021 کا E-Kermit 1.8 یونکس ڈیمو ورژن میں ایک بگ کو درست کرتا ہے جہاں کمانڈ لائن آرگیومینٹس -B اور -T (بالترتیب بائنری اور ٹیکسٹ فائل ٹرانسفر موڈ کو مجبور کرنے کے لیے) کو الٹ دیا گیا تھا۔ اس کی اطلاع دینے کے لیے ٹوڈ مارکلے کا شکریہ۔
27 مئی 2021: اس صفحہ کے تمام ایف ٹی پی لنکس کو HTTP/HTTPS میں تبدیل کر دیا گیا کیونکہ کروم اور فائر فاکس اور کون جانتا ہے کہ دوسرے براؤزرز اب ان کو سپورٹ نہیں کرتے۔ تفصیلات یہاں
مشمولات
- کنٹرول پروگرام
- فائل کی منتقلی
- سورس کوڈ
- یونکس ورژن
- ایک نئے پلیٹ فارم پر پورٹ کرنا
- ڈیبگنگ
- ریلیز کی تاریخ
- ڈاؤن لوڈ کریں
EK (Embedded Kermit, E-Kermit) Kermit فائل ٹرانسفر پروٹوکول کا ایک نفاذ ہے جو ANSI C میں لکھا گیا ہے اور آلات یا فرم ویئر میں سرایت کرنے، ریئل ٹائم ایپلی کیشنز میں استعمال کے لیے، یا DLLs اور لائبریریوں کی تعمیر کے لیے ڈیزائن کیا گیا ہے۔ EKSW E-Kermit کا ایک نیا ورژن ہے جس میں حقیقی سلائیڈنگ ونڈوز پیکٹ ٹرانسپورٹ شامل ہے۔ EK اور EKSW کو ایک ہی کوڈ بیس میں دوبارہ ملایا جانا چاہئے لیکن اب تک ایسا نہیں ہوا ہے۔
E-Kermit کیا کرتا ہے۔
EK صرف دو کام کرتا ہے: فائلیں بھیجنا اور فائلیں وصول کرنا۔ یہ کمپیکٹ، پورٹیبل، اور مکمل طور پر دوبارہ داخل ہونے والا ہے۔ SPARC (RISC) پر، kermit.o تقریباً 25K ہے۔ Intel (CISC) پر یہ تقریباً 15K ہے۔ بفر کے سائز کو کم کرکے اور اختیاری یا ناپسندیدہ خصوصیات کو ختم کرکے، چھوٹے سائز حاصل کیے جاسکتے ہیں۔
E-Kermit کیا نہیں کرتا
EK میں کلائنٹ/سرور کے افعال شامل نہیں ہیں۔ ایک کمانڈ یا اسکرپٹ پروگرامنگ زبان؛ کریکٹر سیٹ کی تبدیلی؛ نقل و حمل کی خفیہ کاری؛ یا مواصلات کی کسی بھی شکل یا فائل ان پٹ/آؤٹ پٹ۔ یہ موڈیم ڈائل نہیں کرتا، یہ کنکشن نہیں بناتا، اس میں بلٹ ان TCP/IP اسٹیک یا کسی بیرونی سے انٹرفیس نہیں ہے۔ اگر آپ کو ان خصوصیات کی ضرورت ہے، تو آپ کو ایک مکمل Kermit پروگرام استعمال کرنا چاہیے، جیسے C-Kermit یا Kermit 95 ۔
EK بذات خود کوئی ایپلیکیشن نہیں ہے، یہ آپ کی ماسٹر ایپلیکیشن سے کال کرنے کا سب روٹین ہے۔ یہ صرف ڈویلپرز کے لیے مفید ہے، جنہیں ماسٹر ایپلیکیشن یا کالنگ ماحول کے ساتھ ساتھ فائل اور کمیونیکیشنز کے معمولات بھی فراہم کرنا چاہیے۔ کال کرنے کے ماحول کو، بدلے میں، مواصلاتی کنکشن بنانا اور کنفیگر کرنا چاہیے اگر کوئی ضروری ہو اور پہلے سے کھلا نہ ہو۔ یونکس کے لیے ایک نمونہ کالنگ ماحول اور i/o سپورٹ فراہم کی گئی ہے۔
صارفین نے EK کو مختلف ماحول اور پلیٹ فارمز میں ڈھال لیا ہے، بشمول پام پائلٹ، مختلف قسم کے ٹیکنیشن آلات (مثلاً سیل فون ٹاورز کی تشخیص اور دیکھ بھال کے لیے)، اور بعض اوقات وہ اپنی موافقت یا i/o معمولات میں حصہ ڈالتے ہیں، اور ہم ان کو دستیاب کر سکتے ہیں۔ سختی سے جیسا کہ ہے۔ ہم گاہک کے تعاون کردہ کوڈ کی حمایت یا برقرار رکھنے کے قابل نہیں ہیں۔ اس طرح (مثال کے طور پر) اگر EK کا نیا ورژن جاری کیا جاتا ہے، تو گاہک کے تعاون سے ماڈیولز ضروری طور پر اپ ڈیٹ نہیں ہوتے۔ کسٹمر کے تعاون کردہ کوڈ میں شامل ہیں:
- Microsoft Windows 9x/ME/NT/2000/XP/Vista/7 سیریل پورٹ اور فائل i/o EK 1.3 اور بعد کے لیے۔
- EK 1.1 کے لیے ونڈ ریور VxWorks ۔
- EK 1.2 کا جاوا میں ترجمہ کیا گیا ۔
EK میں درج ذیل Kermit پروٹوکول خصوصیات شامل ہیں:
- لمبے پیکٹ
- Go-Back-to- N ایرر ریکوری کے ساتھ سلائیڈنگ ونڈوز (EKSW میں صحیح سلیکٹیو ریپیٹ)۔
- دوبارہ گنتی کمپریشن
- کنٹرول کریکٹر پریفکسنگ اور ان پریفکسنگ
- 8 ویں بٹ پریفکسنگ (7 بٹ لنکس پر 8 بٹ ڈیٹا کی منتقلی کے لیے) (= برابری)
- انتساب پیکٹ (قسم، سائز، اور تاریخ)
- ایک یا ایک سے زیادہ فائلیں بھیجنا اور وصول کرنا۔
- خودکار فی فائل ٹیکسٹ/بائنری موڈ سوئچنگ۔
- تینوں بلاک چیک کی اقسام (6- اور 12-بٹ چیکسم، 16-بٹ CRC)۔
- اسٹیٹس رپورٹس (پروٹوکول اسٹیٹ، فائل کا نام، سائز، ٹائم اسٹیمپ، بائٹس اب تک)۔
- کسی بھی فریق کی طرف سے منتقلی کی منسوخی۔
مندرجہ ذیل Kermit پروٹوکول خصوصیات کو نافذ نہیں کیا گیا ہے:
- سلیکٹیو ری ٹرانسمیشن کے ساتھ سلائیڈنگ ونڈوز (سوائے EKSW کے)
- کریکٹر سیٹس
- لاکنگ شفٹس
- کلائنٹ/سرور
ٹائم آؤٹ کنکشن کے دوسرے سرے پر Kermit پروگرام کی ذمہ داری ہو گی یا، اگر E-Kermit ہی میں ضرورت ہو تو، پلیٹ فارم پر منحصر پیکٹ ریڈنگ روٹین جسے آپ لکھیں گے۔
ورژن 1.5 کے مطابق، E-Kermit میں پری پروسیسر کی تعمیرات شامل ہیں تاکہ آپ کو مختلف خصوصیات جیسے کہ لمبے پیکٹ، سلائیڈنگ ونڈوز، اور ہائی آرڈر بلاک چیکس کو خارج کرنے کی اجازت دی جائے تاکہ سب سے چھوٹے ممکنہ میموری فوٹ پرنٹ کو حاصل کیا جا سکے، اور اسے صرف وصول کرنے والی ترتیب میں بھی بنایا جا سکتا ہے۔ .
کنٹرول پروگرام
EK کو کوآپریٹو ملٹی ٹاسکنگ ماحول میں کام کرنے کے لیے ڈیزائن کیا گیا ہے لیکن اسے ایسے ماحول کی ضرورت نہیں ہے۔ کنٹرول پروگرام شیڈولنگ کا خیال رکھتا ہے۔ یہ ہے کہ کنٹرول پروگرام کو کیا کرنا چاہیے (اور/یا کر سکتا ہے):
- اگر چاہیں تو، مواصلاتی آلہ کھولیں، اگر کوئی ہو۔
- اگر چاہیں تو، کمیونیکیشن ڈیوائس، اگر کوئی ہو، "پیکٹ موڈ" میں ڈال دیں۔
- مطلوبہ آپریٹنگ پیرامیٹرز کے ساتھ کرمیٹ ڈھانچہ شروع کریں۔
- کال کریں۔ کرمٹ(K_INIT، ...) Kermit خود کو شروع کرنے کے لئے.
- اگر فائلیں بھیج رہے ہیں تو کال کریں۔ کرمٹ(K_SEND) منتقلی شروع کرنے کے لئے.
(جب E-Kermit فائلیں وصول کرنا ہے، تو یہ فائل بھیجنے والے سے پہلے پیکٹ کا غیر فعال طور پر انتظار کرتا ہے؛ اس طرح یہ آسانی سے پیکٹ لوپ میں داخل ہوتا ہے۔) پیکٹ لوپ میں، E-Kermit:
- ایک بفر حاصل کرتا ہے اور اس میں آنے والا پیکٹ پڑھتا ہے۔
- صارف کی مداخلت کی جانچ کرتا ہے۔
- کالز کرمٹ (K_RUN، ...) پروٹوکول میں اگلا قدم کرنے کے لیے۔
- اور جو چاہے کرتا ہے (مثلاً دوسرے کام چلاتا ہے)۔
- کی بنیاد پر لوپ کو چھوڑتا ہے یا جاری رکھتا ہے۔ کرمٹ() واپسی کوڈ
ہر بار جب کنٹرول پروگرام کال کرتا ہے۔ کرمٹ() فنکشن، یہ اسے ایک پیکٹ کو ہینڈل کرنے کی اجازت دیتا ہے۔ اس طرح ایک پیکٹ = ایک بار کا ٹکڑا۔ اگر کنٹرول پروگرام کے پاس کوئی اور کام نہیں ہے، تو یہ صرف ایک باقاعدہ Kermit پروگرام کی طرح پیکٹوں پر مسلسل کارروائی کرتا ہے۔ ڈیٹا ٹرانسفر لوپ میں رہتے ہوئے، ہر کرمٹ() کال ایک ڈھانچہ لوٹاتا ہے جس پر مشتمل ہے:
- موجودہ پروٹوکول کی حالت؛
- موجودہ فائل کا نام؛
- فائل کا سائز، اگر معلوم ہو، یا -1؛
- فائل کا ٹائم اسٹیمپ، اگر معلوم ہو؛
- اب تک منتقل کیے گئے بائٹس کی تعداد۔
جب ہو جائے، کنٹرول پروگرام:
- بحال کرتا ہے اور (اگر چاہے) مواصلاتی آلہ بند کر دیتا ہے۔
فنکشن کوڈز جنہیں کنٹرول پروگرام کال کر سکتا ہے۔ کرمٹ() کے ساتھ ہیں:
K_INIT -- ڈیٹا ڈھانچے کو شروع کریں۔
K_SEND -- (صرف بھیجنا) -- بھیجنا شروع کریں۔
K_RUN -- پروٹوکول چلائیں۔
K_STATUS -- k_response struct میں اسٹیٹس رپورٹ واپس کریں۔
K_QUIT -- فوراً اور خاموشی سے چھوڑ دیں۔
K_ERROR -- ایرر پیکٹ بھیجیں، پھر چھوڑ دیں۔
کے واپسی کوڈز کرمٹ() فنکشن ہیں:
X_OK -- ٹھیک ہے، پروٹوکول فعال ہے۔
X_DONE -- ٹھیک ہے، پروٹوکول مکمل۔
X_ERROR -- مہلک غلطی.
X_STATUS -- K_STATUS کے جواب میں واپسی کی حیثیت۔
(حقیقت میں ہر کال کے ساتھ اسٹیٹس کو دوبارہ تبدیل کیا جاتا ہے۔) پروٹوکول اسٹیٹ کوڈ یہ ہیں:
-1 -- مہلک غلطی
0 -- وصول کنندہ (پروٹوکول نہیں چل رہا ہے)
1 -- وصول کنندہ ایس پیکٹ کا انتظار کر رہا ہے۔
2 -- وصول کنندہ F یا B پیکٹ کا انتظار کر رہا ہے۔
3 -- وصول کنندہ A یا D پیکٹ کا انتظار کر رہا ہے۔
4 -- وصول کنندہ D یا Z پیکٹ کا انتظار کر رہا ہے۔
10 -- بھیجنے والا (پروٹوکول نہیں چل رہا ہے)
11 -- بھیجنے والے نے ایس پیکٹ بھیجا (شروع)
12 -- بھیجنے والے نے ایف پیکٹ بھیجا (فائل کا نام)
13 -- بھیجنے والے نے ایک پیکٹ بھیجا (اوصاف)
14 -- بھیجنے والے نے ڈی پیکٹ (ڈیٹا) بھیجا
15 -- بھیجنے والے نے زیڈ پیکٹ (EOF) بھیجا
16 -- بھیجنے والے نے بی پیکٹ بھیجا (EOT)
فائل کی منتقلی
چونکہ EK بنیادی طور پر سرایت کرنے کے لیے ڈیزائن کیا گیا ہے، اس لیے یہ سٹریمنگ یا (EKSW کے علاوہ) حقیقی سلائیڈنگ ونڈوز کا استعمال نہیں کرتا ہے (حالانکہ زیادہ تر سلائیڈنگ ونڈوز کوڈ موجود ہے)۔ یہ مندرجہ ذیل وجوہات کی بناء پر ہے:
- باقاعدہ ACK/NAK پروٹوکول کا استعمال کنٹرول پروگرام کو ہر پیکٹ کے بعد دوبارہ کنٹرول حاصل کرنے کی اجازت دیتا ہے۔ یہ اسے ملٹی ٹاسک کرنے دیتا ہے، گرافیکل فائل ٹرانسفر ڈسپلے لگاتا ہے، جو بھی ہو۔ سٹریمنگ یا سلائیڈنگ ونڈوز کنٹرول پروگرام کو طویل عرصے تک کاروبار سے باہر رکھ سکتی ہیں۔
- سٹریمنگ یا حقیقی سلائیڈنگ ونڈوز کنٹرول پروگرام اور کے درمیان انٹرفیس بنائے گی۔ کرمٹ() ماڈیول بہت زیادہ پیچیدہ، اور درحقیقت، پروٹوکول کی بہت ساری تفصیلات کو کنٹرول پروگرام کی جگہ میں دھکیل دے گا، جہاں ان کا تعلق نہیں ہے۔
- سٹریمنگ کا استعمال صرف قابل اعتماد کنکشنز (جیسے TCP/IP) پر کیا جا سکتا ہے لیکن ایمبیڈڈ کمیونیکیشن والے آلات عام طور پر سیریل پورٹس استعمال کرتے ہیں۔
EK میں حقیقی سلائیڈنگ ونڈوز کی کمی کی تلافی EK کی طرف سے ان کی حمایت کرنے کا بہانہ کرکے کیا جاتا ہے۔ یہ اس کے بھیجنے والے پارٹنر کو ہر ایک کے بعد ACKs کا انتظار کرنے کے بجائے پیکٹوں کو "سٹریم" کرنے کی اجازت دیتا ہے، جب تک کہ کوئی خرابی نہ ہو۔ اگر کوئی خرابی ہے تو، بازیابی کی حکمت عملی "انتخابی تکرار" کے بجائے " n پر واپس جائیں" (یا شاید کچھ معاملات میں "خرابی ختم") ہے۔ EKSW، ایک علیحدہ پروگرام جسے EK کے ساتھ مربوط نہیں کیا گیا ہے (لیکن ہونا چاہیے)، سلیکٹیو ریپیٹ کے ساتھ حقیقی سلائیڈنگ ونڈوز کو سپورٹ کرتا ہے۔ یعنی، صرف وہی پیکٹ دوبارہ منتقل کیے جاتے ہیں جن کی اصل میں ضرورت ہوتی ہے۔
کسی بھی صورت میں، چونکہ EK کا مقصد بنیادی طور پر سرایت کرنا ہے، اس لیے یہ توقع کی جاتی ہے کہ راؤنڈ ٹرپ میں تاخیر ایک بڑا عنصر نہیں ہو گی۔ کنکشن عام طور پر مقامی، مختصر، نسبتاً تیز ہوں گے، اور اگر کنکشن مؤثر طریقے سے بہاؤ کو کنٹرول کیا جائے تو، غلطی سے پاک۔ جب موثر بہاؤ کنٹرول کا فقدان ہو تو، رفتار اور/یا پیکٹ کی لمبائی اور/یا ونڈو کے سائز کو قدروں کے مجموعہ پر سیٹ کیا جا سکتا ہے جو تھرو پٹ کو زیادہ سے زیادہ کرتا ہے اور ڈیٹا کے نقصان کو کم کرتا ہے۔
سورس کوڈ
ماخذ فائلیں ہیں:
کسی بھی ضروری پلیٹ فارم کے لیے مخصوص #includes یا تعریفوں کے لیے ہیڈر فائل۔ ضروری ہے، چاہے یہ خالی ہی کیوں نہ ہو۔ kermit.c اس میں شامل ہے.
تمام ماڈیولز کے لیے ہیڈر فائل۔ کی تعریف k_data اور k_response ڈھانچے
یہ Kermit پروٹوکول انجن ہے۔ یہ مکمل طور پر اس کے کال ڈیٹا سے چلتا ہے۔ تمام ریاستی معلومات کرمٹ ڈیٹا سٹرکچر میں محفوظ کی جاتی ہیں، جو کہ مین ماڈیول کے حوالے سے اور کرمٹ ماڈیول کے تمام فنکشنز میں سے گزر کر دوبارہ مین ماڈیول میں جاتی ہے۔ اس طرح ایک ہی ماڈیول کے لیے مختلف کنکشنز پر ایک ساتھ متعدد فائلوں کو منتقل کرنا ممکن ہونا چاہیے۔ مزید برآں، کرمٹ ماڈیول میں لائبریری کے حوالے نہیں ہیں، کوئی بھی نہیں، یہاں تک کہ stdio بھی نہیں (سوائے اس کے جب ڈیبگنگ فعال ہو)، اور نہیں /usr/include/* ہیڈر فائلیں شامل ہیں۔ کے لیے قواعد kermit.c :
- کوئی عالمی متغیر (سوائے ڈیبگنگ کے) یا بفرز نہیں۔
- کمپائلر کے ذریعہ صفوں کی شروعات نہیں ہے۔
- صرف حفاظت کے لیے، خودکار اسکیلرز کو بھی شروع نہیں کرنا۔
- کوئی لائبریری یا سسٹم کالز نہیں، نہیں۔ #شامل کریں <...> .
- تمام مواصلات i/o الگ الگ ماڈیولز میں بیان کردہ فنکشنز کے ذریعے کیے جاتے ہیں۔
کے لیے واحد اندراج پوائنٹ kermit.c ماڈیول ہے کرمٹ() فنکشن:
int kermit (struct k_data * k، struct k_response * r)
k ڈھانچہ تمام آپریٹنگ پیرامیٹرز، متغیرات، ریاستی معلومات، اور بفرز پر مشتمل ہے ۔ r ڈھانچہ کال کرنے والے کو پروٹوکول کی موجودہ حالت، فائل کا نام اور فائل کی معلومات، اور منتقلی کی پیشرفت (اب تک بائٹس) سے باخبر رکھتا ہے ۔
نمونہ کنٹرول پروگرام۔ یونکس ٹیسٹ بیڈ میں، یہ صرف روایتی ہے۔ مرکزی() ، جو کمانڈ لائن آرگیومینٹس کو پڑھتا ہے، پروٹوکول کو شروع کرتا ہے، پھر پروٹوکول ماڈیول کو ریاست سے چلنے والے لوپ میں کال کرتا ہے جب تک کہ اس کا کام نہ ہو جائے، پھر صاف ہو جائے۔ ایمبیڈڈ ماحول میں، ان افعال کو کنٹرول پروگرام میں ضم کیا جائے گا۔
یونکس کے لیے I/O فنکشنز۔ اپنے ماڈیول کو تبدیل کریں جو ان افعال کو ہدف کے ماحول میں لاگو کرتا ہے اور اس کے ساتھ لنک کرنے کے لیے اپنے تعمیراتی طریقہ کار میں ترمیم کریں۔ داخلہ پوائنٹس اور کالنگ کنونشنز ذیل میں بیان کیے گئے ہیں۔
یونکس ورژن
EK کی ترقی روایتی یونکس پلیٹ فارم پر ہوتی ہے، جیسے Mac OS، AIX، Solaris، HP-UX، ... یا ان دنوں زیادہ امکان ہے کہ BSD یا Linux کی کچھ اقسام، جس میں EK کو ریموٹ موڈ Kermit کے طور پر بنایا گیا ہے۔ فائل ٹرانسفر پروگرام، G-Kermit کی طرح، اور ڈیسک ٹاپ Kermit جیسے K95 یا C-Kermit کے خلاف تجربہ کیا گیا۔ نوٹ: یونکس ورژن stdin/stdout پر کام کرتا ہے۔ "لائن" کو ممکنہ احمقانہ طریقے سے مشروط کیا گیا ہے ( سسٹم ("stty ...") )۔ یہ متغیر نتائج دیتا ہے؛ مثال کے طور پر سولاریس پر EK سے ڈاؤن لوڈز 17Kcps پر چل سکتے ہیں، جبکہ لینکس سے اسی نیٹ پر ایک ہی PC پر ڈاؤن لوڈز 1700Kcps پر چل سکتے ہیں۔ یہ فکر کرنے کے قابل نہیں ہے کیونکہ EK یونکس پر پیداواری استعمال کے لیے نہیں ہے، جس میں پہلے سے ہی G-Kermit اور C-Kermit موجود ہے۔
یونکس میک فائل کے درج ذیل اہداف ہیں (مزید شامل کرنا آسان ہے):
جی سی سی: جی سی سی (پہلے سے طے شدہ) کے ساتھ بنائیں۔
سی سی: سی سی کے ساتھ تعمیر کریں۔
hp: HP-UX کے لیے تعمیر کریں۔
gccnd: جی سی سی کے ساتھ بنائیں، کوئی ڈیبگنگ نہیں۔
gprof: جی سی سی کے ساتھ بنائیں، پروفائلنگ شامل کریں۔
صاف: آبجیکٹ اور بنیادی فائلوں کو ہٹا دیں۔
میک فائل ایک یونکس ایگزیکیوٹیبل بناتی ہے جسے "ek" (ایمبیڈڈ کرمٹ) کہتے ہیں۔ نمونہ مرکزی() روٹین ایک سادہ کمانڈ لائن انٹرفیس فراہم کرتا ہے:
.
_ _
_
_
_ _ _
_
_ 2، یا 3 (پہلے سے طے شدہ = 3)
-k نامکمل طور پر موصول ہونے والی فائلوں کو رکھیں
-B فورس بائنری موڈ
-T فورس ٹیکسٹ موڈ
-R ریموٹ موڈ (بمقابلہ لوکل)
-L لوکل موڈ (بمقابلہ ریموٹ)
-E نمبر نقلی غلطی کی شرح (0- 100)
-d بنائیں debug.log
-h مدد (یہ پیغام)
$
فائلیں بھیجتے وقت، اگر آپ متن یا بائنری کی وضاحت نہیں کرتے ہیں، تو EK ہر فائل کو اسکین کرتا ہے اور اس کے مواد کی بنیاد پر متن یا بائنری وضع کا انتخاب کرتا ہے۔
ریموٹ بمقابلہ لوکل موڈ صرف فائل کی منتقلی میں کی بورڈ رکاوٹ کے ٹیسٹ کو فعال کرنے کے لیے استعمال کیا جاتا ہے۔
ایک نئے پلیٹ فارم پر پورٹ کرنا
EK کا ورژن 1.0 Airvana, Inc, Chelmsford MA کے ذریعے VxWorks پر پورٹ کیا گیا تھا۔ مکمل VxWorks EK 1.1 پیکیج کو Airvana کی اجازت سے پروڈکشن سسٹم کی ایک مثال کے طور پر شامل کیا گیا ہے (نوٹ کریں کہ EK API اس کے بعد سے تھوڑا سا تبدیل ہوا ہے، لہذا VxWorks کوڈ کو استعمال کرنے سے پہلے، اسے اپ ڈیٹ کرنا ضروری ہے)۔ ایک نئے پلیٹ فارم پر پورٹ کرنے کے لیے:
- اپنے ہدف کے لیے ایک نیا میک فائل اندراج شامل کریں، یا اپنا خود ساختہ طریقہ کار لکھیں۔
- بنائیے ایک platform.h آپ کے پلیٹ فارم کے لیے فائل۔ اس میں کوئی بھی مطلوبہ #include's یا تعریفیں شامل ہو سکتی ہیں، اور اس میں کچھ تعریفوں کو اوور رائیڈ کرنے کے لیے بھی استعمال کیا جا سکتا ہے۔ kermit.h :
# نوڈبگ کی وضاحت کریں۔ ڈیبگنگ کوڈ کے بغیر تعمیر کرنا۔
#HAVE_UCHAR کی وضاحت کریں۔ اگر UCHAR پہلے ہی بیان کیا گیا ہے یا typedef غیر دستخط شدہ چار پر d۔
#HAVE_ULONG کی وضاحت کریں۔ اگر ULONG پہلے ہی بیان کیا گیا ہے یا typedef طویل عرصے سے غیر دستخط کرنے کے لئے.
#IBUFLEN کی وضاحت کریں۔ فائل ان پٹ بفر کے لیے مطلوبہ سائز ہونا۔
#OBUFLEN کی وضاحت کریں۔ فائل آؤٹ پٹ بفر کے لیے مطلوبہ سائز ہونا۔
#FN_MAX کی وضاحت کریں۔ فائل نام کے لیے زیادہ سے زیادہ لمبائی ہونا۔
# P_PKTLEN کی وضاحت کریں۔ پہلے سے طے شدہ زیادہ سے زیادہ پیکٹ کی لمبائی کو اوور رائیڈ کرنے کے لیے۔
# P_WSLOTS کی وضاحت کریں۔ پہلے سے طے شدہ زیادہ سے زیادہ ونڈو سلاٹس کو اوور رائڈ کرنے کے لیے۔ - نمونہ بدل دیں۔ main.c آپ کے اپنے کنٹرول پروگرام کے ساتھ۔ وہی ہیڈر فائلز اور کالنگ کنونشن استعمال کریں جیسا کہ نمونہ میں ہے۔
- کاپی unixio.c کوxxx io.c (اپنی پسند کا نام)، بالکل وہی کالنگ کنونشنز کا استعمال کرتے ہوئے اپنے پلیٹ فارم پر کام کرنے کے لیے اس میں ترمیم کریں، اور اپنے نئے کے ساتھ لنک کرنے کے لیے اپنے تعمیراتی طریقہ کار کو ایڈجسٹ کریں۔xxx io اس کے بجائے ماڈیول unixio . نوٹ کریں کہ فل ان پٹ اور آؤٹ پٹ بفرز ( i_buf[] اور o_buf[] ) کی تعریف آپ میں ہونی چاہیے۔xxx io معمول
i/o ماڈیول بنانے کے لیے یہاں چند تجاویز ہیں:
ڈیوائس i/o روٹینز سے توقع کی جاتی ہے کہ وہ مواصلاتی پیرامیٹرز کو خود ہینڈل کریں گے، بشمول کمیونیکیشن لائن کی رفتار، برابری، اور بہاؤ کنٹرول۔ خاص طور پر، Kermit برابری کو نہیں سنبھالتا، لیکن پھر بھی اس کے بارے میں بتانا ضروری ہے۔ یہ کی طرف سے سیٹ اپ میں کیا جاتا ہے مرکزی() . آپ کا readpkt() اور tx_data() اگر ضروری ہو تو معمولات کو بالترتیب برابری اور برابری کا اضافہ کرنا چاہیے۔ سیریل کنکشن پر، شاید UART کو ایسا کرنے کے لیے پروگرام کیا جا سکتا ہے۔
EK 1.1 اور 1.2 کے درمیان API کی تبدیلی: کالنگ کنونشنز (فنکشن آرگیومینٹ لسٹ اور ریٹرن ویلیوز) کو ورژن 1.1 سے 1.2 کے درمیان تبدیل کیا گیا، بنیادی طور پر تمام معمولات کو k سٹرککٹ تک مسلسل رسائی دینے کے لیے ، اور کال کرنے والے کو بہتر فیڈ بیک فراہم کرنے کے لیے۔ . ہر صورت میں جہاں تبدیلی کی گئی تھی، پرانا اور نیا فارمیٹ دکھایا گیا ہے۔
ڈیوائس i/o کے افعال ہیں:
انٹ
ڈیوپن (چار * ڈیوائس)
دیا ہوا مواصلاتی آلہ کھولتا ہے۔ نیٹ ورک ہوسٹ بھی ہو سکتا ہے، جو بھی ہو۔ ناکامی پر 0، کامیابی پر 1 لوٹاتا ہے۔
int
devsettings (char * ترتیبات)
یہ آلہ کے لیے کوئی بھی ضروری ترتیبات انجام دیتا ہے، جیسے کہ سیریل ڈیوائس کے لیے رفتار اور بہاؤ کنٹرول۔ چونکہ یہ جاننے کا کوئی طریقہ نہیں ہے کہ متعلقہ پیرامیٹرز کیا ہیں، اس لیے یہ معمول صرف ایک تار لیتا ہے، جو کسی بھی شکل میں ہو سکتا ہے، جیسے " 9600;8N1 "یا" رفتار=57600;flow=rts/cts "؛ ڈیو سیٹنگز روٹین کو اسٹرنگ کو پارس کرنا ہوگا۔ ناکامی پر 0، کامیابی پر 1 لوٹاتا ہے۔
int
devrestore (باطل)
اگر چاہیں تو، آلہ کو واپس راستے پر رکھیں ڈی سیٹنگز() اسے ملا، جیسے اسے بند کرنے سے پہلے۔
int
devclose (باطل)
مواصلاتی آلہ بند کر دیتا ہے۔
int
readpkt (UCHAR * بفر، struct k_data * k) (1.1)
readpkt(struct k_data * k، UCHAR * بفر، int length) (1.2)
اس روٹین کو بالکل وہی کرنا چاہیے جو نمونہ کرتا ہے: پیکٹ کے آغاز کے لیے تلاش کریں، پھر پیکٹ کے آخر تک (لیکن شامل نہیں) تمام حروف کو پیکٹ بفر میں کاپی کریں جس کا پتہ دیا گیا ہے۔ آپ اس کو ہر ممکن حد تک موثر طریقے سے کوڈ کرنا چاہیں گے، جو بھی آپ کے لیے دستیاب ہیں: نان بلاکنگ بفرڈ ریڈز وغیرہ۔ اگر آپ چاہتے ہیں کہ آپ کے کیرمٹ پروگرام کا وقت ختم ہو، تو یہیں آپ کوڈ ڈالیں گے۔ نوٹ: ٹائم آؤٹ ضروری نہیں ہے، کیونکہ ek کے Kermit پارٹنر کے وقت ختم نہ ہونے کے امکانات تقریباً 0 ہیں۔ EK 1.2 فارمیٹ k کو دوسرے معمولات کے ساتھ مستقل مزاجی کے لیے پہلی دلیل کے طور پر رکھتا ہے، اور بفر کی لمبائی کی دلیل کا اضافہ کرتا ہے۔
F_CTRLC کی خصوصیت کو نوٹ کریں۔ یہ بطور ڈیفالٹ فعال ہے۔ یہ EK کو ڈیٹا سٹریم میں لگاتار تین Ctrl-C بھیج کر پیکٹ موڈ سے الگ ہونے کی اجازت دیتا ہے۔ آپ کو عام طور پر اسے غیر فعال کرنے کی ضرورت نہیں ہوگی کیونکہ، یہاں تک کہ اگر بھیجنے والا Ctrl-C کو "غیر سابقہ" کر رہا ہے، ان میں سے تین لگاتار عام طور پر دوبارہ گنتی کی ترتیب میں سمٹ جائیں گے۔
int
tx_data (UCHAR * ڈیٹا، int لمبائی، مختصر برابری) (1.1)
tx_data(struct k_data * k، UCHAR * ڈیٹا، int length) (1.2)
یہاں ایک بار پھر، آپ کو برابری پر کام کرنا ہوگا (اگر یہ مواصلاتی آلہ یا ڈرائیور کے ذریعہ خود بخود نہیں ہو رہا ہے)۔ یہ معمول موثر اور مضبوط دونوں ہونا چاہیے۔ سمجھا جاتا ہے کہ یہ پوری ڈیٹا سٹرنگ کو منتقل کرے گا یا پھر ناکام ہوجائے گا۔ دیکھیں unixio.c "مضبوط" سے میرا کیا مطلب ہے اس کا نمونہ۔ EK 1.2 اور بعد میں، برابری کی ترتیب کو k ڈھانچے سے اٹھایا جاتا ہے ۔
فائل i/o کے افعال درج ذیل ہیں۔ یقیناً وہ کچھ بھی پڑھنے یا لکھنے کے لیے استعمال کیے جا سکتے ہیں -- نہ صرف فائلیں: میموری، ٹیپ، کارڈز، لیزر بیم، انسٹرومنٹ کنٹرولرز، جو کچھ بھی ہو۔ اس سے کوئی فرق نہیں پڑتا کہ آپ ان معمولات کو کیا کہتے ہیں، لیکن دلیل کی فہرست اور واپسی کی قسم اسی طرح ہونی چاہیے جیسا کہ دکھایا گیا ہے۔ اس کے علاوہ اگر آپ انہیں مختلف نام دیتے ہیں، تو آپ کو پروٹو ٹائپ کو تبدیل کرنا پڑے گا۔ kermit.h :
int
اوپن فائل (UCHAR * فائل کا نام، int موڈ، ساخت k_date * k) (1.1)
openfile(struct k_date * k، UCHAR * فائل کا نام، int موڈ) (1.2)
نامزد کردہ فائل کو دیئے گئے موڈ میں کھولتا ہے (1 = پڑھنا، 2 = لکھنا، 3 = ضمیمہ)۔ کامیابی پر X_OK، ناکامی پر X_ERROR لوٹاتا ہے۔
ULONG
فائل کی معلومات (UCHAR * فائل کا نام، UCHAR * buf، int buflen، مختصر * قسم، مختصر موڈ) (1.1)
fileinfo(struct k_data * k,UCHAR * فائل کا نام,UCHAR * buf,int buflen, short * type, short mode) (1.2)
مخصوص موجودہ مقامی فائل کے بارے میں معلومات حاصل کرتا ہے: سائز، تاریخ، اور اگر موڈ == 0، فائل کی قسم (متن یا بائنری)۔ buf اور buflen فائل کی تاریخ/وقت کی تار پر لاگو ہوتے ہیں۔ X_OK یا X_ERROR لوٹاتا ہے۔
int
readfile (struct k_data *)
ان پٹ فائل سے بفر پڑھتا ہے، اور اگر ٹرانسفر ٹیکسٹ موڈ میں ہے، تو ریکارڈ فارمیٹ کو معیاری Kermit Stream CRLF میں بدل دیتا ہے۔ X_OK یا X_ERROR لوٹاتا ہے۔
int
writefile (struct k_data *، CHAR * بفر، int کی لمبائی)
آؤٹ پٹ فائل پر بفر لکھتا ہے، اور اگر ٹرانسفر ٹیکسٹ موڈ میں ہے، تو معیاری Kermit Stream CRLF ریکارڈ فارمیٹ کو بھی مقامی طور پر مطلوبہ فارمیٹ میں تبدیل کرتا ہے۔ X_OK یا X_ERROR لوٹاتا ہے۔
int
Closefile (struct k_data *، UCHAR کوڈ، int موڈ)
فائل بند کر دیتا ہے۔ آؤٹ پٹ فائلوں کے لیے، یقیناً یہ فائل کو بند کرنے سے پہلے کسی بھی زیر التواء بفر کو فلش کرتا ہے۔ پھر یہ چیک کرتا ہے کہ آیا بھیجنے والے Kermit نے فائل کی منتقلی کو ختم ہونے سے پہلے ہی منسوخ کر دیا ہے (کوڈ == 'D')، ایسی صورت میں یہ جزوی فائل کو رکھنے کے بجائے ضائع کر دیتا ہے۔ موڈ بتاتا ہے کہ آیا یہ ان پٹ فائل ہے یا آؤٹ پٹ، لہذا نامکمل موصول ہونے والی فائلوں کو اگر چاہیں تو حذف کیا جا سکتا ہے۔ X_OK یا X_ERROR لوٹاتا ہے۔
عین مطابق کالنگ کنونشنز میں دکھائے گئے ہیں۔ unixio.c فائل
ڈیبگنگ
اگر EK کو NODEBUG کی وضاحت کے بغیر بنایا گیا تھا، تو اگر آپ اس میں شامل ہیں۔ -d کمانڈ لائن پر آپشن، EK کا یونکس پر مبنی نمونہ ورژن ایک تخلیق کرتا ہے۔ debug.log فائل اس کی موجودہ ڈائرکٹری میں۔ پروڈکشن ورژن میں، آپ ڈیبگنگ کوڈ کو ختم کرنے کے لیے C کمپائلر CFLAGS میں -DNODEBUG شامل کریں گے۔ اوپر دکھائے گئے سائز میں ڈیبگنگ شامل ہے۔ آپ اپنے پلیٹ فارم کے مخصوص i/o ماڈیول میں ڈیبگ فنکشن کو کسی بھی طرح سے لاگو کر سکتے ہیں۔
ریلیز کی تاریخ
|
ورژن |
تاریخ |
تفصیل |
|
1.1 |
2002/10/07 |
ابتدائی رہائی. VxWorks ورژن اب بھی اس سطح پر ہے۔ |
|
1.2 |
2003/01/28 |
بہتر API، جاوا پورٹ (جو اب بھی اس سطح پر ہے)۔ |
|
1.3 |
2004/03/04 |
ہائپر ٹرمینل کے ساتھ فائل کی منتقلی کو درست کریں۔ |
|
1.4 |
2004/03/20 |
خالی فائلوں کا استقبال درست کریں۔ |
|
1.5 |
2004/04/10 |
A-Packets کے ساتھ مسئلہ حل کریں، انتہائی چھوٹے اور/یا صرف وصول کرنے والے کنفیگریشن کی اجازت دیں۔ |
|
1.51 |
23/09/2004 |
Philips XAG30 (John Dunlap) کو اپنائیں |
|
EKSW 0.94 |
24/06/2010 |
سلیکٹیو ری ٹرانسمیشن کے ساتھ حقیقی سلائیڈنگ ونڈوز ( جان ڈنلاپ ) |
|
1.6 |
2011/03/30 |
3-Clause Revised BSD لائسنس کے تحت شائع اور جاری کیا گیا ۔ |
|
1.7 |
2011/06/06 |
FORCE-3 پروٹوکول، C-Kermit 9.0 کے ساتھ مل کر کام کرتا ہے ( یہاں وضاحت کی گئی ہے ) |
|
1.8 |
26/06/2021 |
-B اور -T کمانڈ لائن دلیل کے ساتھ مسئلہ حل کریں (صرف یونکس ڈیمو) |
ڈاؤن لوڈ کریں
کئی مختلف E-Kermit نفاذ ڈاؤن لوڈ کے لیے دستیاب ہیں۔ E-Kermit خود، ورژن 1.8، بنیادی ہے۔ ورژن 1.7 دستیاب ہے۔ دیگر مختلف پلیٹ فارمز یا زبانوں کے موافقت ہیں جو E-Kermit کی پیشگی ریلیز کے دوران کیے گئے تھے، جیسا کہ پچھلے حصے میں اشارہ کیا گیا ہے۔ دوسرے الفاظ میں، E-Kermit 1.3، 1.4، اور 1.5 میں پائی جانے والی اصلاحات VxWorks یا Java ورژن میں نہیں ہیں، اور VxWorks ورژن بہتر 1.2 ورژن کی بجائے E-Kermit 1.1 API استعمال کرتا ہے۔ EKSW میں API میں کچھ ترامیم اور دیگر تضادات ہیں جنہیں EK 1.6 کے ساتھ ضم کرنے سے پہلے اسے ختم کر دیا جانا چاہیے، لیکن یہ خود ہی بالکل قابل استعمال ہے۔ درحقیقت، یہ ایپیکس-EM سمندری فلوٹس کی نئی نسل میں چلنے والا ورژن ہے۔اور ممکنہ طور پر کسی دوسرے Kermit پروٹوکول کے نفاذ کے مقابلے میں زیادہ منفی حالات میں زیادہ اچھی طرح سے جانچا گیا ہے۔ ورژن 1.7 کو جنم دینا، جو نئے فورس-3 ایرر چیکنگ پیکٹ پروٹوکول کو لاگو کرتا ہے۔ (EKSW کو یہ بھی کسی وقت مل جانا چاہئے۔)
|
نام |
تفصیل |
تار * |
زپ |
ماخذ فائلیں۔ |
|
E-Kermit 1.8 |
یونکس ڈیمو کے ساتھ تمام پلیٹ فارمز کے لیے پورٹ ایبل۔ |
|||
|
E-Kermit 1.7 |
یونکس ڈیمو کے ساتھ تمام پلیٹ فارمز کے لیے پورٹ ایبل۔ |
|||
|
EKSW 0.94 |
E-Kermit حقیقی سلائیڈنگ ونڈوز کے ساتھ، لینکس کے مطابق۔ |
|||
|
EKVX 1.1 |
E-Kermit 1.1 کو VxWorks کے مطابق ڈھال لیا گیا۔ |
|||
|
جاوا |
E-Kermit 1.2 کو جاوا میں تبدیل کر دیا گیا۔ |
|||
|
سمیرڈ |
کرمٹ پروٹوکول اسٹریس ٹیسٹر [ تفصیل ] |
* کمپریسڈ نہیں، ضرورت نہیں، وہ بہت چھوٹے ہیں۔