به طور خلاصه، Indy اجزایی برای کار راحت با پروتکل های اینترنتی محبوب است. اصل عملکرد آنها بر اساس استفاده از سوکت ها در حالت مسدود است. ایندی جالب و راحت است زیرا کاملاً انتزاعی است. و برنامه نویسی در ایندی به برنامه نویسی خطی خلاصه می شود. به هر حال، یک مقاله ترجمه شده به طور گسترده در اینترنت توزیع شده است که در آن عبارت "حالت مسدود کردن شیطان نیست" وجود دارد :)) زمانی من با این ترجمه بسیار سرگرم شدم. این مقاله بخشی از کتاب «عمق ایندی» نوشته هوور و حریری است. در اصل، برای کار با Indy لازم نیست همه آن را بخوانید، اما همچنان توصیه می کنم با اصول نحوه کار پروتکل های اینترنت آشنا شوید. در مورد رژیم "شیطانی". یک تماس سوکت مسدود کننده تا زمانی که وظیفه خود را کامل نکرده باشد، در واقع کنترل را بر نمی گرداند. وقتی تماس‌ها روی رشته اصلی برقرار می‌شود، رابط برنامه ممکن است مسدود شود. برای جلوگیری از این وضعیت ناخوشایند، توسعه دهندگان هندی مولفه TIdAntiFreeze را ایجاد کردند. شما فقط باید آن را روی فرم بیندازید - و هنگام برقراری تماس های مسدود شده، رابط کاربری به راحتی دوباره ترسیم می شود.

احتمالاً قبلاً با محتویات تب های مختلف «ایندی (...)» در دلفی آشنا شده اید. اجزای زیادی در آنجا وجود دارد و هر یک از آنها می تواند مفید باشد. من خودم با همه کار نکرده ام، زیرا نیازی به مطالعه آنها بدون کار خاصی نمی بینم.

توزیع اصلی دلفی شامل Indy v.9 با پنی است. احتمالاً بهتر است فوراً به موارد بیشتری ارتقا دهید نسخه جدید(مثلاً من در حال حاضر 10.0.76 دارم، اما به نظر می رسد نسخه های بعدی هم وجود دارد).

اجزای کلاینت و سرور برای کار با پروتکل های یکسان وجود دارد. Indy واقعاً توسعه برنامه را ساده می کند، برخلاف گزینه توسعه همان عملکرد در سوکت ها. به عنوان مثال، برای برقراری ارتباط با سرور، فقط باید روش Connect را فراخوانی کنید. برقراری اتصال موفق با روش بازگشت بدون ایجاد استثنا علامت گذاری می شود. اگر اتصال برقرار نشود، یک استثنا ایجاد می شود.

مثال "آکادمیک" (کد کار نمی کند، آن را اجرا نکنید :)):

با IndyClient انجام دهید
شروع
میزبان:= "test.com";
بندر:= 2000;
اتصال؛
تلاش كردن
// کار با داده ها (خواندن، نوشتن...)
سرانجام
قطع شدن؛
پایان؛
پایان؛

میزبان و پورت را می توان در بازرس شی یا در زمان اجرا تنظیم کرد.

چرا می توانید از کامپوننت های Indy در تجزیه وظایف استفاده کنید؟ کاربردهای مختلف! ساده ترین کار این است که محتویات صفحه را با استفاده از مؤلفه IdHTTP دریافت کنید (احتمالاً همه قبلاً با آن مواجه شده اند):

Var
rcvdata: TMemoryStream;
idHttp1: TidHttp;
شروع
idHttp1:= TidHttp.Create(nil);
rcvrdata:= TMemoryStream.Create;
idHttp1.Request.UserAgent:= "Mozilla/4.0 (سازگار؛ MSIE 5.5؛ Windows 98)";
idHttp1.Request.AcceptLanguage:= "ru";
idHttp1.Response.KeepAlive:= true;
idHttp1.HandleRedirects:= true;
تلاش كردن
idHttp1.Get(Edit1.Text، rcvdata);
سرانجام
idHttp1.Free;
پایان؛
اگر rcvrdata.Size > 0 باشد، شروع کنید
ShowMessage("دریافت" + inttostr(rcvrdata.Size));
rcvrdata.SaveToFile("c:\111.tmp");
پایان؛
rcvrdata.Free;
پایان؛

همانطور که می بینید، نه تنها می توانید محتویات صفحه را دریافت کنید، بلکه بارگذاری یک سند را از یک مشتری خاص نیز شبیه سازی کنید. کامپوننت های Indy عموما برای تولید هدرها و درخواست های POST مفید هستند. دفعه بعد با مثال هایی در این مورد بیشتر توضیح دهید.

برای به روز ماندن از به روز رسانی وبلاگ، می توانید

اجزای Indy مورد استفاده در دلفی 6.

علاوه بر سرویس ها و پروتکل های اولیه اینترنت، طیف گسترده ای از خدمات اضافی نیز وجود دارد که اغلب توسعه دهندگان اینترنت از قابلیت های آن استفاده می کنند. علاوه بر این، امکان نمایش اطلاعات با استفاده از مرورگر همیشه راه حل قابل قبولی برای برنامه های اینترنتی نیست. در این مورد، منطقی است که از زیرساخت اینترنت برای تبادل داده ها استفاده کنیم و نمایش اطلاعات را از طریق برنامه های کاربردی مشتری پیچیده تر توسعه یافته، به عنوان مثال، در دلفی فراهم کنیم.

فرض کنید باید منطق سرور تخصصی را پیاده سازی کنید که در وب سرورهای استاندارد گنجانده نشده است. برای حل این دسته از مشکلات، دلفی شامل کتابخانه اینترنت مستقیم (Indy) از Nevrona Designs (http://www.nevrona.com/Indy/) است. این کتابخانه که به طور خاص برای Borland Delphi توسعه یافته است، در حال حاضر دارای هشت نسخه است که آخرین آنها در نسخه جدید دلفی گنجانده شده است. مجموعه کامپوننت ها به سه گروه کلاینت (Indy Client)، سرور (Indy Servers) و کمکی (Indy Misc) تقسیم می شوند.

مشتریان ایندی و سرورهای ایندی

بیشتر مؤلفه‌های Indy Client و Indy Servers جفت‌هایی هستند که مربوط به بخش‌های کلاینت و سرور پروتکل‌ها و سرویس‌ها هستند (به استثنای مؤلفه‌های خاص، عمدتاً سرور، مانند TunnelMaster و TunnelSlave)، و اجازه استفاده از پروتکل‌هایی مانند TCP/IP را می‌دهند. ، UDP، NNTP، SMTP، FTP، HTTP، و همچنین خدمات ECHO، FINGER، WHOIS و غیره.

اجزای سرویس گیرنده Indy با استفاده از سوکت ها نوشته می شوند. سوکت سمت کلاینت نیاز به اتصال به سرور دارد. اگر اتصال برقرار شود، سرویس گیرنده و سرور می توانند شروع به تبادل پیام کنند. این پیام ها ماهیت متفاوتی دارند، اما معمولا تبادل با استفاده از یک پروتکل خاص (به عنوان مثال، HTTP) انجام می شود.

TIdTCPClient و TIdTCPServer

این مؤلفه‌ها برای پشتیبانی از یکی از پروتکل‌های اصلی شبکه - TCP (پروتکل کنترل انتقال) استفاده می‌شوند و همچنین کلاس‌های پایه برای مؤلفه‌های TIdSMTP و TIdFTP هستند. کلاس TIdTCPServer دارای یک ویژگی ThreadMgr است که به طور پیش فرض صفر است. اگر وقتی TIdTCPServer فعال است ThreadMgr صفر باشد، کلاس TIdThreadMgrDeafault به طور ضمنی ایجاد می شود. در غیر این صورت، از مدیر فرآیند نصب شده استفاده می شود.

TIdUDPClient و TIdUDPServer

از این قطعات برای پشتیبانی استفاده می شود پروتکل شبکه UDP (پروتکل دیتاگرام کاربر) و همچنین کلاس های پایه برای تعدادی دیگر از اجزای Indy هستند.

TIdChargenServer

مولفه برای تولید نمادهای تصادفی، معمولاً برای اهداف آزمایشی استفاده می شود.

TIdDayTime و TIdDayTimeServer

مولفه ها برای ارائه سرویس زمان استفاده می شوند. مشتری درخواست می کند و سرور تاریخ و زمان فعلی را گزارش می دهد.

TIdDNSResolver

این یک مؤلفه مشتری است که درخواست های یک سرور DNS (سرویس نام دامنه) را ارائه می دهد. پرس و جوهای سرور DNS برای جایگزینی نام رایانه با آدرس IP آن طراحی شده اند. TIdDNSResolver از نوادگان کلاس TIdUDPClient است.

TIdDICTServer

یک جزء سرور که از Dictionary Server Protocol (DICT) پشتیبانی می کند، یک فرهنگ لغت سمت سرور مبتنی بر پروتکل TCP که به مشتری امکان دسترسی به فرهنگ لغت زبان طبیعی را می دهد.

TIdDISCARDServer

جزء سروری که از سرور رکوردها پشتیبانی می کند. ضبط ها را می توان به عنوان یک ابزار اشکال زدایی و اندازه گیری استفاده کرد. سرویس سوابق به سادگی هر داده ای را به هر کسی که مایل به دریافت آن است تحویل می دهد.

TI dEcho و TI dECHOServer

اجزا برای ارائه یک سرویس پاسخ طراحی شده اند که معمولاً برای بررسی سلامت شبکه استفاده می شود. مشتری یک پیام متنی به سرور ارسال می کند، سرور پیام را به مشتری برمی گرداند. اگر پیام مخدوش باشد، شبکه دچار مشکل می شود.

TIdFinger و TIdFingerServer

اجزا به گونه ای طراحی شده اند که پروتکلی را ارائه دهند که به کاربر اجازه می دهد داده های مربوط به حضور سایر کاربران را در سیستم پرس و جو کند. برخی از سرورها چنین درخواست های مشتری را مدیریت می کنند. استفاده از این جفت مؤلفه به شما این امکان را می‌دهد تا به درخواست‌های مشتری سرویس دهید که حضور سایر کاربران را در سیستم تعیین می‌کند.

TIdFTP

این مؤلفه شامل پشتیبانی کامل از پروتکل انتقال فایل - FTP (پروتکل انتقال فایل) است. انتقال داده غیرفعال و فعال و همچنین عملیاتی مانند GET و PUT، حذف دایرکتوری ها، به دست آوردن سهمیه، اندازه فایل و دایرکتوری پشتیبانی می شود. TI dFTP از کلاس TIdSimpleServer برای عملکرد استفاده می کند. هنگامی که انتقال فایل FTP در حال انجام است، یک اتصال TCP ثانویه برای انتقال داده باز می شود و پس از انتقال داده بسته می شود. این اتصال "پیوند داده" نامیده می شود که برای هر فایلی که منتقل می شود منحصر به فرد است.

TIdGopher و TIdGopherServer

این اجزا برای ارائه یک پروتکل شبکه ای طراحی شده اند که جایگزین آن شده است اخیرااز WWW (World وب گسترده) پروتکل HTTP. سروری که این پروتکل را پیاده‌سازی می‌کند، یک سیستم پشتیبانی از جریان سند توزیع شده سلسله مراتبی ارائه می‌کند. نمونه ای از این جفت کامپوننت که در دایرکتوری های \demos\indy\GopherClient و \demos\indy\GopherServer قرار دارد، نشان می دهد که چگونه می توان از این پروتکل برای ارائه استفاده کرد. شبکه محلیاطلاعات مربوط به فایل های موجود در رایانه شما، از جمله فایل های بسته.

TIdHostNameServer

یک جزء سرور طراحی شده برای ارسال نام سرور محلی به مشتریان.

سرور TIdHTTP و TIdHTTPS

مؤلفه ها برای ارائه پروتکل شبکه HTTP استفاده می شوند (نسخه های 1.0 و 1.1 پشتیبانی می شوند، از جمله عملیات GET، POST و HEAD). علاوه بر این، پشتیبانی برای احراز هویت و استفاده از سرورهای پروکسی ارائه می شود. جزء سرور برای ارائه خدمات به وب سرور دیگری که از پروتکل معینی پشتیبانی می کند استفاده می شود. TIdHTTPServer اجرای عملکردهایی مانند کوکی ها، مدیریت حالت و غیره را تسهیل می کند.

TIdIcmpClient

یک جزء مشتری طراحی شده برای ارائه پروتکل پیام کنترل اینترنت (ICMP)، که برای انجام عملیات پینگ و ردیابی شبکه استفاده می شود.

TIdPOP3

یک جزء مشتری طراحی شده برای ارائه پروتکل Post Office (POP)، شامل پشتیبانی از رمزگذاری و رمزگشایی MIME، و انتقال کاراکتر چند بایتی.

سرور TIdIMAP4

یک جزء سرور طراحی شده برای پشتیبانی از عملیات IMAP (پروتکل دسترسی به پیام های اینترنتی) روی سرور. پروتکل به شما امکان می دهد پیام ها را جستجو کنید پست الکترونیکروی سرور تفاوت بین پروتکل های IMAP و POP این است که پروتکل POP نیاز دارد حافظه اضافیبرای ذخیره داده ها، و پروتکل IMAP به جای ماشین سرویس گیرنده به سرور دسترسی پیدا می کند. IMAP4 برای جایگزینی POP3 ایجاد شد، اما POP3 تا به امروز یک استاندارد پرکاربرد باقی مانده است.

سرور TIdIRCS

یک مؤلفه سرور طراحی شده برای پشتیبانی از متداول ترین عملیات سرویس مورد استفاده در اینترنت که معمولاً چت نامیده می شود. مؤلفه اساسی را ارائه می دهد بلوک های ساختمانبرای سرور IRC (Internet Relay Chat).

TIdMappedPortTCP

یک جزء سرور طراحی شده برای ایجاد پورت های نقشه برداری شده، که اغلب در سرورهای پروکسی استفاده می شود. روش های این کامپوننت به شما امکان می دهد یک پورت را به پورت دیگر نگاشت کنید. به عنوان مثال، پورت 80 را می توان به پورت 3000 نگاشت، و تمام درخواست ها به پورت اول (پورت 80) به پورت دوم (پورت 3000) ارسال می شود.

سرور TIdNNTP و TIdNNTPS

این مؤلفه‌ها برای پشتیبانی از پروتکل انتقال اخبار شبکه (NNTP) مورد استفاده در سرویس‌های خبری مورد نیاز هستند. مؤلفه مشتری شامل پشتیبانی از رمزگذاری و رمزگشایی MIME، و همچنین پشتیبانی از کاراکترهای چند بایتی و رمزگذاری های جایگزین است. مؤلفه سرور به شما امکان می دهد سرورهای خبری ایجاد کنید. توجه به این نکته مهم است که TIdNNTPServer یک سرور خبری با امکانات کامل نیست، بلکه مؤلفه‌ای است که عملکرد اولیه چنین سروری را فراهم می‌کند.

TIdQOTD و TIdQOTDSserver

مولفه ها برای ارائه خدمات نقل قول روز استفاده می شوند. مؤلفه مشتری به نمونه مؤلفه سرور متصل می شود تا قیمت روزانه را به دست آورد. هر نمونه سرور شامل یک پایگاه داده استنادی منحصر به فرد است.

TIdSMTP

یک مؤلفه مشتری که برای استفاده در برنامه های کاربردی پروتکل انتقال نامه ساده (SMTP) طراحی شده است و از احراز هویت، رمزگذاری و رمزگشایی MIME و پشتیبانی از کاراکترهای چند بایتی پشتیبانی می کند.

TIdSNTP

یک جزء مشتری طراحی شده برای ارائه SNTP (پروتکل زمان شبکه ساده) - یک سرویس زمان. می توان از آن برای اتصال به هر سرویس زمانی برای تعیین تاریخ و زمان فعلی استفاده کرد.

TIdSimpleServer

جزء سرور که یک سرور TCP سبک وزن را فراهم می کند. به شما امکان می دهد یک اتصال نقطه به نقطه را سازماندهی کنید. برای ایجاد سرور با یک کاربر استفاده می شود، یعنی می تواند در هر زمان فقط یک اتصال را ارائه دهد. برخلاف مؤلفه TIdTCPServer، در هنگام انتظار برای درخواست‌های مشتریان و هنگام پردازش این درخواست‌ها، فرآیندهای ثانویه ایجاد نمی‌کند. به عبارت دیگر، اگر سرور در حال سرویس دهی درخواستی از یک کلاینت باشد و در آن زمان کلاینت دیگری برای اتصال با آن تماس بگیرد، تا پایان پردازش درخواست اول مسدود خواهد شد.

TIdTelnet و TIdTelnetServer

مؤلفه کلاینت برای سازماندهی جلسات راه دور در رایانه دیگری، از جمله مذاکرات کنسول و تأیید اعتبار استفاده می شود. پروتکل ارتباطی حضور یک شخص را در تعامل با سرور فرض می کند. مؤلفه کلاینت پشتیبانی از نمایشگر یا شبیه سازی ترمینال ندارد، بلکه به سادگی یک اتصال به بخش سرور را فراهم می کند. به طور معمول، پروتکل سرور TIdTelnetServer برای سازماندهی پایگاه داده های راه دور با یک رابط متنی برای تعامل تعاملی با مشتریان استفاده می شود.

TIdTime و TIdTimeServer

مؤلفه مشتری جایگزینی برای مؤلفه TIdSNTP برای تعیین زمان است. لازم به ذکر است که فرمت های این دو پروتکل متفاوت است. TIdTime بر اساس فرمت RFC 868 است (زمان را در استاندارد داخلی UNIX OS، انجام تمام تبدیل‌های لازم برمی‌گرداند). مؤلفه سرور از نظر عملکرد مشابه سرور DayTime است. می توان از آن برای پیاده سازی سرویس زمان در استفاده کرد کامپیوتر محلی. هیچ کد اضافی مورد نیاز نیست، فقط یک نمونه از TIdTimeServer ایجاد کنید که زمان ساعت داخلی کامپیوتر سرور را برمی گرداند.

TIdTrivialFTP و TIdTrivialFTPServer

این اجزا برای سازماندهی یک پروتکل ساده انتقال فایل ضروری هستند. مؤلفه مشتری این پروتکل برای اتصال به نمونه ای از مؤلفه سرور مربوطه استفاده می شود. این پروتکل برای موارد خصوصی، سبک و محلی انتقال فایل، به عنوان مثال در شبکه های محلی یا برای بارگذاری (آپلود) جداول مسیریابی در روترها در نظر گرفته شده است. با توجه به ویژگی های ضعیف این پروتکل، استفاده از آن در هنگام استفاده از الگوریتم های احراز هویت یا هر مکانیزم امنیتی دیگر توصیه نمی شود. هدف اصلی این پروتکل انتقال فایل ها به یک دستگاه سخت افزاری به منظور تغییر آن است.

TIdTunnelMaster و TIdTunnelSlave

اجزای تونل سرور در سرورهای پروکسی برای سازماندهی چندین اتصال منطقی در یک فیزیکی (تونل) استفاده می شود. این کلاس ها را می توان برای اهداف مختلفی استفاده کرد، به عنوان مثال، برای سازماندهی یک اتصال مخفی در کانال های غیر مخفی.

TIdWhois و TIdWhoIsServer

این جزء مشتری به هر سرور استاندارد Whois متصل می شود و به شما امکان می دهد اطلاعاتی در مورد دامنه ها به دست آورید. مؤلفه سرور، عملکرد اصلی یک سرور NIC را فراهم می کند.

ایندی متفرقه

صفحه پالت اجزای متفرقه Indy شامل BASE64، UUE، Quoted Printable و سایر فرمت‌های ارتباطی رایج ایمیل، رمزگذارها (MD2، MD4 و MD5) برای استانداردهای رمزنگاری مورد استفاده برای ذخیره رمزهای عبور و امضای الکترونیکیبه شکل غیر قابل برگشت (به سختی رمزگشایی) و همچنین بسیاری از مؤلفه ها و ابزارهای مفید دیگر که اغلب در توسعه برنامه های کاربردی اینترنتی استفاده می شوند.

TIdAntiFreeze

با توجه به الگوریتم های مبتنی بر بلوک اجزای Indy، اغلب به نظر می رسد که برنامه زمانی که اتصال کار می کند گیر کرده است. برای حذف استفاده از فرآیندهای ثانویه (رشته ها) هنگام سازماندهی ارتباطات برای جلوگیری از انجماد برنامه، کافی است جزء مشخص شده را روی فرم قرار دهید.

این مؤلفه با تجزیه درخواست‌ها از پشته پروتکل TCP/IP و ارسال پیام به برنامه در طول تأخیر زمانی که اتصالات خارجی مسدود می‌شوند کار می‌کند، که این توهم کد در حال اجرا را ایجاد می‌کند. از آنجایی که کامپوننت بر روی اتصالات مسدود شده فقط برای فرآیند اصلی تأثیر می گذارد، استفاده از TIdAntiFreeze در فرآیندهای ثانویه برنامه مورد نیاز نیست. توجه داشته باشید که مؤلفه TIdAntiFreeze اتصالات را کند می کند زیرا فرآیند اصلی به طور دوره ای برای پردازش پیام ها قطع می شود. بنابراین باید مراقب بود که برنامه در حال توسعه زمان زیادی را برای پردازش پیام‌ها از جمله OnClick، OnPaint، OnResize و غیره صرف نمی‌کند. استفاده از این مؤلفه اجباری نیست، اما به شما امکان می دهد مشکل همگام سازی اتصالات با رابط بصری برنامه را حل کنید.

TIdDateTimeStamp

کلاسی برای انجام ریاضیات تاریخ و زمان مربوط به این واقعیت است که پروتکل های اینترنتی از فرمت های مختلف تاریخ و زمان استفاده می کنند. علاوه بر این، کلاینت ها و سرورها ممکن است در مناطق زمانی مختلف قرار داشته باشند.

TIdIPWatch

این یک جزء مبتنی بر تایمر است که دائماً تغییرات آدرس IP رایانه را کنترل می کند. رویدادهای مؤلفه زمانی رخ می دهند که تغییری شناسایی شود. این کامپوننت معمولا برای تشخیص اینکه آیا کامپیوتر به اینترنت یا هر شبکه دیگری متصل است استفاده می شود. تغییر در آدرس IP در این وضعیت ممکن است به دلیل تخصیص آدرس IP توسط سرور DHCP (پروتکل پیکربندی میزبان پویا) هنگام اتصال به شبکه جدید رخ دهد.

TIdLogDebug

هدف این مؤلفه رهگیری رویدادهای هر مؤلفه مشتری یا سرور و قرار دادن رکورد رویداد در آن است فایل مشخص شده. این کامپوننت برای اشکال زدایی کامپوننت های Indy بسیار مفید است.

TIdMessage

این مؤلفه در ترکیب با سایر مؤلفه ها برای رمزگشایی یا رمزگذاری صحیح پیام ها استفاده می شود. اینها می توانند اجزای POP، SMTP و NNTP باشند. کلاس از رمزگذاری و رمزگشایی MIME، کاراکترهای چند بایتی و کدگذاری ISO پشتیبانی می کند.

TIdNetwork Calculator

یکی از معدود مؤلفه‌های Indy که می‌توان هنگام ساخت برنامه‌ها از آن استفاده کرد. از ماشین حساب شبکه می توان برای انجام محاسبات روی آدرس های IP از جمله ماسک های شبکه، زیر شبکه، کلاس های شبکه و غیره استفاده کرد.

TIdThreadMgrDefault

کامپوننت به طور پیش فرض کنترل فرآیندهای ثانویه را فراهم می کند. زمانی ایجاد می شود که هر جزء Indy که از مدیریت فرآیند پشتیبانی می کند نمونه ای از کلاس TIdThreadManager تعریف نشده باشد. این مؤلفه فقط قابلیت های اساسی را برای مدیریت فرآیندهای ثانویه فراهم می کند: ایجاد و از بین بردن آنها در صورت تقاضا.

TIdThreadMgrPool

یک جزء مدیریت فرآیند پیشرفته‌تر از TIdThreadMgrDefault، زیرا فرآیندها را به جای ایجاد یا از بین بردن آنها در صورت تقاضا، ادغام می‌کند.

TIdVCard

VCard معادل الکترونیکی کارت ویزیت است و ممکن است حاوی اطلاعات شخصی و اطلاعات گرافیکی مالک باشد.

TIdIMFDecoder

طراحی شده برای رمزگشایی پیام های اینترنتی. مانند سایر اجزای رمزگذار، از نسل TIdCoder است. کلاس TIdCoder بر اساس استاندارد قالب پیام متنی اینترنتی ARPA RFS-822، پیشنهاد شده در آگوست 1982، و استاندارد پیام رسانی USENET RFC 1036، پیشنهاد شده در دسامبر 1987، رمزگشایی می شود.

این مؤلفه کلاس TIdCoder را گسترش می دهد تا امکان تشخیص فرمت RFS-822 توسط زمینه هدر، ارائه حالت رمزگشایی در دریافت و رمزگذاری و رمزگشایی MIME را فراهم کند. جزء TIdIMFDecoder در کلاس TIdMessageClient برای رمزگشایی پیام های دریافتی و ارسال شده استفاده می شود.

TIdQuotedPrintableEncoder

QuotedPrintableEncoder به شما امکان می دهد متن را در قالب مشخص شده رمزگشایی کنید. می تواند به عنوان یک مؤلفه مستقل با یک نوع رمزگذاری مشخص عمل کند و به پیام های حاوی یک نوع رمزگذاری جدید اجازه انتقال داده شود.

TIdBase64Encoder

الگوریتم رمزگذاری دیگری را پیاده سازی می کند که امکان انتقال کاراکترهای غیر قابل چاپ را فراهم می کند.

TIdUUEncoder

یکی از اولین الگوریتم های رمزگذاری، رمزگذاری UU را پیاده سازی می کند. گاهی اوقات هنگام ارسال مقالات به یک سرویس خبری استفاده می شود.

TIdXXEncoder

بعید است که هرگز از این روش رمزگذاری استفاده شود. در اصل، این همان رمزگذاری UU است، اما با جدول رمزگذاری متفاوت.

TIdCoderMD2

اجزای با انواع مختلف الگوریتم رمزگذاری MD (Message Digest). همه آنها مبتنی بر ترکیب، یک طرفه هستند و هیچ الگوریتم رمزگشایی ندارند.

اجزای کلاینت‌ها و سرورهای پروتکل را می‌توان برای توسعه برنامه‌های کاربردی اینترنت سرور و کلاینت، همراه با یا به جای برنامه‌های اصلی (ClientSocket، ServerSocket) و سایر اجزای اینترنت و پالت Fastnet استفاده کرد. مؤلفه‌های Indy از معماری WebBroker استفاده نمی‌کنند، و پشتیبانی سطح پایین را برای پروتکل‌ها و سرویس‌های اینترنتی به‌طور مستقیم در کد منبع خود پیاده‌سازی می‌کنند. کدهای منبعضمیمه شده اند).

TIdConnectionInterceptOpenSSL و TIdServerInterceptOpenSSL

پروتکل SSL - Secure Sockets Layer که محرمانه بودن و قابلیت اطمینان ارتباط بین دو برنامه را تضمین می کند، دارای دو لایه است. در سطح پایین یک پروتکل حمل و نقل چند لایه (مانند TCP)، SSL یک پروتکل ضبط است و برای کپسوله کردن پروتکل های مختلف سطح بالاتر استفاده می شود. مزیت SSL این است که یک پروتکل کاربردی مستقل است، اما می توان از یک پروتکل سطح بالاتر در بالای SSL استفاده کرد.

SSL امنیت ارتباطات را فراهم می کند که دارای سه عملکرد اصلی است: ارائه یک اتصال محرمانه. رمزگذاری با کلید عمومی(برای تأیید صحت مخاطب استفاده می شود)؛ پشتیبانی از قابلیت اطمینان انتقال داده

• رمزنگاری متقارن برای رمزگذاری داده ها (مانند DES، RC4 و غیره) استفاده می شود.
• امضای دیجیتالیبا استفاده از رمزگذاری نامتقارن کلید عمومی (به عنوان مثال، RSA، DSS، و غیره) ارائه می شود.
• قابلیت اطمینان ارتباط، انتقال پیام شامل بررسی یکپارچگی پیام از طریق کدهای تصحیح MAC، توابع هش ایمن (مانند SHA، MD5 و غیره) با استفاده از محاسبات MAC است.

SSL در ترکیب با HTTP و احراز هویت سرور، توابع رمزگذاری لازم را فراهم می کند و با بررسی متقاطع هویت وب سرور و غیره، اتصال برقرار شده را حفظ می کند. درک این نکته مهم است که SSL فقط از ارتباطات در حین انتقال داده محافظت می کند و جایگزین مکانیسم های امنیتی دیگر نمی شود.

اجزای TIdConnectionInterceptOpenSSL و TIdServerInterceptOpenSSL هر دو اتصال سمت سرویس گیرنده و سمت سرور را با استفاده از پروتکل SSL فراهم می کنند. لازم به ذکر است که اجزای TIdConnectionInterceptOpenSSL و TIdServerInterceptOpenSSL فقط در دلفی 6 موجود هستند، اما در Kylix موجود نیستند. این به دلیل پیچیدگی پروتکل است که در مورد اجرای ویندوز بر اساس عملکردهای سیستم عامل است.

نمونه هایی از استفاده از مؤلفه های Indy را می توان در دایرکتوری های /Delphi6/Demos/Indy یافت. در مجموع، کتابخانه Indy در نسخه 8.0 شامل 69 جزء است. بیان شده است که در نسخه 9.0 کتابخانه مشخص شده شامل 86 جزء خواهد بود. همه اجزای یکپارچه شده و در دلفی 6 و کیلیکس گنجانده شده‌اند، که به آنها اجازه می‌دهد برای توسعه برنامه‌های چند پلتفرمی استفاده شوند. همه اجزای Indy از multithreading پشتیبانی می کنند.

اجزای Indy تقریباً تمام عملکردهای موجود در مؤلفه های اینترنت و Fastnet را اجرا می کنند، همانطور که به وضوح در جدول نشان داده شده است.

	اجزای Fastn et	اجزای ایندی	هدف اجزاء
1	TserverSocket، TClientSocket	TIdTCPserverSocket، TIdTCPClientSocket	تعامل بین دو کامپیوتر (کلاینت و سرور) با استفاده از پروتکل TCP/IP
2	TNMDayTime	TIdDayTime، TIdDayTimeServer	سرور را برای زمان فعلی پرس و جو کنید
3	TNMEcho	TIdEcho، TIdEchoServer	برای ارتباط با سرور پاسخ استفاده می شود
4	TNMFinger	TIdFinger، TIdFingerServer	برای به دست آوردن اطلاعات در مورد کاربر از سرور جستجوی اینترنتی استفاده می شود
5	TNMFTP	سرور TIdFTP، TIdTrivialFTP، TIdTrivialFTPS	امکان انتقال فایل با استفاده از پروتکل FTP
6	TNMHTTP	سرور TIdHTTP، TIdHTTPS	از پروتکل HTTP برای تبادل داده استفاده کنید
7	TNMMsgServ، TNMMsg		برای انتقال ساده استفاده می شود پیام های متنیاز مشتری به سرور
8	TNMNNTP	سرور TIdNNTP، TIdNNTPS	پشتیبانی از تبادل داده با سرور اخبار
9	TNMPOP3	TIdPOP3	برای دریافت ایمیل از سرور ایمیل با استفاده از پروتکل POP3 استفاده می شود
10	TNMSMTP	TIdSMTP	برای ارسال ایمیل از طریق سرور پست الکترونیکیاینترنت
11	TNMStrm، TNMStrmServ		داده های باینری را با استفاده از پروتکل TCP/IP به یک جریان ارسال می کند
12	TNMUDP	TIdUDP، TIdUDPServer	انتقال داده ها با استفاده از پروتکل UDP
13	TpowerSock، TNMGeneralServer		کلاس‌های کپسوله‌شده با مؤلفه‌ها که مبنای نوشتن کلاینت‌های خود (Powersock) و سرورها (NMGeneralServer) هستند.
14	پردازنده TNMUUP	TIdUUEncoder، TIdUUDecoder	رمزگذاری مجدد را انجام دهید فایل های باینریبه فرمت MIME یا UUENCODE
15	TNMURL		رشته ها را به فرمت HTML تبدیل می کند و تبدیل معکوس را انجام می دهد

استثناها کلاس‌هایی مانند TNMMsgServ، TNMMsg، TNMStrm، TNMStrmServ، TpowerSock، TNMGeneralServer، TNMURL هستند که یا پروتکل‌های منسوخ را پیاده‌سازی می‌کنند یا دارای عملکرد پیاده‌سازی شده در گروه بزرگی از کلاس‌های جایگزین هستند.

با این حال، بر خلاف پیشینیان خود - اینترنت و اجزای Fastnet، Indy شامل اجزای سرور و مؤلفه‌های غنی‌تری برای رمزگذاری و رمزگذاری داده‌ها، و همچنین پشتیبانی از احراز هویت (پالت Indy Misc) است. همانطور که از جدول بالا مشاهده می شود، پروتکل ها و خدمات اصلی نه تنها توسط مشتری، بلکه توسط اجزای سرور نیز ارائه می شوند. اینها خدمات زمان، خدمات پاسخگویی، به دست آوردن اطلاعات کاربر، و همچنین پروتکل های HTTP، NNTP، UDP و حتی ساده ترین نسخه FTP هستند.

چند نمونه از استفاده از کامپوننت های Indy

در مؤلفه‌های Indy موجود در دلفی، آدرس IP در ویژگی Host، معمولاً فقط در برنامه‌های کلاینت تعریف می‌شود. مؤلفه‌های میزبان سرور روش‌هایی دارند که به شما امکان می‌دهند نظرسنجی درگاه مربوطه را شروع یا متوقف کنید - برای مثال، تغییر ویژگی Active مؤلفه IdTCPServer، نظرسنجی پورت مربوطه را شروع یا متوقف می‌کند. هنگامی که ارتباط بین سرویس گیرنده و سرور برقرار شد، انتقال داده می تواند آغاز شود.

اجزای Indy تاکید زیادی بر امنیت و قابلیت اطمینان هنگام کار با داده ها دارند. برای مثال، مؤلفه IdTCPClient دارای متدهای Connect و Disconnect است. با استفاده از یک تکنیک برنامه نویسی مانند کد زیر از سمت مشتری:

با TCPClient شروع به اتصال کنید. lstMain.Items.Add(ReadLn) را امتحان کنید. در نهایت قطع اتصال؛ پایان؛ پایان؛

و با استفاده از ویژگی Connection به عنوان یک پارامتر به نمونه AThread کلاس TIdPeerThread از سمت سرور ارسال می شود:

با AThread.Connection، WriteLn را شروع کنید ("سلام از سرور اصلی ایندی سرور."); قطع شدن؛ پایان؛

می توانید روی اجرای عادی اتصال یا مدیریت صحیح خطا حساب کنید.

به متدهای ReadLn و WriteLn کلاس‌های مربوطه توجه کنید - آنها شبیه دستورات استاندارد پاسکال I/O هستند. این ادای احترام به تکنیک برنامه نویسی یونیکس است که در آن اکثر عملیات سیستم با خواندن و نوشتن در فایل های مربوطه انجام می شود.

درست مانند مؤلفه‌های Fastnet، کلاس‌های مؤلفه Indy رویدادهایی دارند که می‌توان از آنها برای ارائه مدیریت رویداد استفاده کرد. به عنوان مثال، می توانید ترتیبی دهید که هنگام اتصال به یک کلاینت، پیامی در فرم نمایش داده شود:

روش TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); start lblStatus.caption:= "[ خدمت به مشتری ]"; پایان؛

Indy اجزایی را ارائه می دهد که پروتکل ها را با بخش های کلاینت و سرور پیاده سازی می کند که منحصر به این کتابخانه است. اجزای TIdGopherServer و TIdGopher به لطف متدهای GetExtendedMenu، GetFile، GetMenu، GetTextFile در سمت کلاینت و ReturnGopherItem، SendDirectoryEntry در سمت سرور، به مشاهده فایل ها کمک می کنند. انواع مختلف، از جمله مواردی که به عنوان پنهان علامت گذاری شده اند، و همچنین فهرست های موجود در کامپیوتر از راه دور(مشابه نحوه انجام دستور dir *.* در سیستم عامل MS-DOS).

با استفاده از مؤلفه های IdSMTP و IdMessage، می توانید به راحتی برنامه وب خود را ایجاد کنید که می تواند با استفاده از پروتکل SMTP نامه ارسال کند.

در این حالت، کلاس IdMessage (یکی از 23 مؤلفه از صفحه Indy Misc) مسئول تولید پیام است که از نام آن بر می‌آید و IdSMTP برای سازماندهی ارتباط با سرور ایمیل است.

فناوری مورد استفاده در Indy از عملیات قفل خواندن و نوشتن استفاده می کند. هر عملیات اتصالی که در Indy استفاده می‌شود منتظر می‌ماند تا اتصال کامل شود. هنگام کار با اجزای مشتری Indy، معمولاً باید موارد زیر را انجام دهید:

• درخواست اتصال به سرور؛
• درخواست خواندن و نوشتن به سرور (بسته به نوع سرور، مرحله یک بار انجام می شود یا چندین بار تکرار می شود).
• اتصال به سرور را قطع کرده و قطع کنید.

اجزای Indy طوری طراحی شده اند که سطح فوق العاده بالایی از انتزاع را ارائه دهند. پیچیدگی ها و جزئیات پشته TCP/IP از دید برنامه نویس پنهان می شود تا بتواند بر روی کار مورد نظر تمرکز کند.

مثال کوچک زیر یک جلسه معمولی کلاینت را نشان می دهد:

با IndyClient شروع میزبان:= "zip.pbe.com"; // میزبان برای تماس پورت:= 6000; // پورت برای تماس با سرور در اتصال. سعی کنید // کد شما به اینجا می رود در نهایت قطع اتصال. پایان؛ پایان؛

در مثال، حتی اگر اتصال به سرور برقرار نشود، به دلیل استفاده از دستور try-finally، اتصال به راحتی قطع می شود.

اجزای سرور ایندی انواع مدل‌های سرور را توصیف می‌کنند که بسته به نیاز شما و پروتکلی که استفاده می‌کنید می‌توان از آنها استفاده کرد.

TIdTCPServer رایج ترین مؤلفه سرور مورد استفاده است که یک فرآیند ثانویه مستقل از فرآیند برنامه اصلی ایجاد می کند. فرآیند ایجاد شده منتظر درخواست های دریافتی از طرف می ماند مشتریان بالقوه. یک فرآیند ثانویه فردی برای هر مشتری که به درخواست آن پاسخ می دهد ایجاد می شود. رویدادهایی که در طول فرآیند تعمیر و نگهداری اتفاق می‌افتند به زمینه فرآیندهای مربوطه مربوط می‌شوند.

به عبارت دیگر، برای هر اتصال کلاینت، کلاس TIdTCPServer از یک رشته ثانویه منحصر به فرد با فراخوانی رویداد OnExecute آن رشته استفاده می کند. پارامتر رسمی متد OnExecute ارجاع به نمونه ای از کلاس Athread مربوط به رشته ایجاد شده است. ویژگی Connection این کلاس مرجعی به کلاس TIdTCPConnection است که نمونه ای از آن برای پردازش درخواست مشتری ایجاد می شود. TIdTCPConnection از خواندن و نوشتن از طریق اتصال و همچنین برقراری و خاتمه یک جلسه ارتباطی پشتیبانی می کند.

پروتکل UDP بدون ایجاد ارتباط با سرور کار می کند (هر بسته ارسالی مجموعه ای مستقل از داده ها است و بخشی از یک جلسه یا اتصال بزرگتر نیست). در حالی که TIdTCPServer رشته های جداگانه ای را برای هر اتصال ایجاد می کند، TIdUDPServer از یک رشته اصلی یا یک رشته ثانویه استفاده می کند که تمام درخواست های پروتکل UDP را مدیریت می کند. هنگامی که TIdUDPServer فعال است، یک رشته برای گوش دادن به بسته های UDP ورودی ایجاد می شود. برای هر بسته دریافتی، بسته به مقدار ویژگی ThreadedEvent، یک رویداد OnUDRead یا در رشته اصلی یا در زمینه رشته شنیداری مطرح می‌شود. هنگامی که ThreadedEvent به False ارزیابی می شود، رویداد در رشته اصلی رخ می دهد، در غیر این صورت در رشته شنیداری رخ می دهد. در حالی که رویداد در حال پردازش است، سایر عملیات سرور مسدود می شوند. بنابراین، مهم است که اطمینان حاصل شود که رویه های OnUDRead در سریع ترین زمان ممکن اجرا می شوند.

اگر نیاز به ایجاد یک برنامه کلاینت جدید برای سرور موجود با استفاده از پروتکل موجود دارید، وظیفه شما صرفاً توسعه و اشکال زدایی برنامه مشتری است. با این حال، زمانی که شما باید هم مشتری و هم برنامه سرورچه از یک پروتکل موجود یا یک پروتکل جدید استفاده کنیم، ما با مشکل کلاسیک "مرغ و تخم مرغ" روبرو هستیم. برنامه نویسی را از کجا شروع کنیم - از مشتری یا از سرور؟

بدیهی است که هم کلاینت و هم سرور باید در نهایت ایجاد شوند. برای بسیاری از برنامه ها، به ویژه آنهایی که از پروتکل مبتنی بر متن (مانند HTTP) استفاده می کنند، شروع ساخت برنامه با طراحی سرور آسان تر است. و برای رفع اشکال یک کلاینت راحت وجود دارد که از قبل وجود دارد. این یک برنامه کنسول Telnet است که هم در ویندوز و هم در یونیکس موجود است.

اگر کنسول را تایپ کنید دستور تلنت 127.0.0.1 80 با آدرس IP رایانه محلی و شماره پورت 80 که به طور پیش فرض توسط سرورهای وب استفاده می شود، سپس برنامه با متن نشان داده شده در شکل پاسخ می دهد. 6، در مورد سیستم عامل ویندوز 2000 و IIS 5.0.

برای ایجاد ساده ترین سرور با استفاده از مؤلفه های Indy به موارد زیر نیاز دارید:

اگر نیاز به طراحی سروری دارید که نه تنها هنگام قطع اتصال به مشتریان خود به درستی اطلاع دهد، بلکه اطلاعاتی در مورد موقعیت های خطای رخ داده در اختیار آنها قرار دهد، به جای try-finally از عبارت try-except استفاده کنید - به عنوان مثال، در مثال زیر نشان داده شده است:

Procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: رشته; با AThread.Connection شروع کنید s:= ReadLn را امتحان کنید. // وظیفه سرور را در اینجا انجام دهید // اگر هیچ استثنایی مطرح نشد، // پاسخ سرور WriteLn(های) را بنویسید؛ به جز در e: Exception do begin WriteLn(e.Message); end; //در پایان; // سعی کنید به جز در نهایت قطع، پایان، پایان.

این مثال کوچک مراحل ایجاد یک سرور متنی ساده و همچنین نحوه اشکال زدایی آن را نشان می دهد.

سروری که در بالا توضیح داده شد یک نمونه معمولی از سازماندهی محاسبات توزیع شده مدرن است.

ویژگی های ایجاد اپلیکیشن های چند لایه

اخیراً چندین سرور به طور فزاینده ای برای برآوردن درخواست های مشتری استفاده می شود. سروری از این نوع، پس از دریافت درخواست مشتری و آماده سازی جزئی آن برای پردازش بیشتر، با سرور دیگری تماس می گیرد و درخواست یا درخواست های تبدیل شده را برای آن ارسال می کند. سرور رده دوم به نوبه خود می تواند با سرورهای دیگر ارتباط برقرار کند. بنابراین، ما می توانیم در مورد معماری سرور چند لایه صحبت کنیم.

در مرحله بعد یک سرور دسترسی به داده ایجاد می کنیم که هدف آن برگرداندن داده ها از پایگاه داده است. با این حال، این سرور مستقیماً فایل های پایگاه داده را نمی خواند یا نمی نویسد. در عوض، در جستجوی داده های مورد نیاز مشتری با سرور پایگاه داده ارتباط برقرار می کند.

بنابراین، ما شروع به توسعه یک برنامه با معماری سه لایه می کنیم. برای ایجاد یک سرور پایگاه داده با استفاده از مؤلفه های Indy به موارد زیر نیاز دارید:

1. یک پروژه جدید ایجاد کنید.
2. نمونه ای از مولفه TIdTCPServer را از پالت Indy Servers در فرم اصلی پروژه قرار دهید.
3. ویژگی DefaultPort نمونه کلاس TIdTCPServer1 را روی 6001 تنظیم کنید (توصیه می‌شود برای جلوگیری از تکرار شماره پورت در برنامه‌های مختلف، مقادیر بزرگی را اختصاص دهید)، و ویژگی Active را روی true تنظیم کنید.
4. با انتخاب File | یک ماژول جدید به پروژه اضافه کنید جدید | ماژول داده، و نمونه هایی از مولفه های SQLConnection و SQLDataSet را از زبانه dbExpress در پالت مؤلفه ها روی آن قرار دهید.
5. ویژگی ConnectionName کلاس SQLConnection را روی IBLocal و LoginPrompt را روی False قرار دهید. اگر IBLocal را در پایگاه داده staff.gdb پیکربندی نکرده اید، ابتدا این روش را تکمیل کنید.
6. ویژگی SQLConnection کلاس SQLDataSet را بر روی SQLConnection1 قرار دهید و ویژگی را به CommandText اختصاص دهید. بیانیه SQL: CUSTOMER، CONTACT_FIRST، CONTACT_LAST را از CUSTOMER انتخاب کنید که در آن CUST_NO = :cust.

سرژ دوسیوکوف مایک فام

این مقاله نحوه ایجاد یک وب سرویس مستقل با استفاده از کیت Indy و دلفی 7 و نحوه استفاده از کیت Indy برای پشتیبانی از خدمات وب مبتنی بر دلفی 7 SOAP را به شما نشان می دهد. پشت اطلاعات اضافیبرای کسب اطلاعات در مورد ایجاد خدمات وب، به مقاله عالی نیک هاجز در سایت انجمن Borland مراجعه کنید: Shakespeare on the Web.

دیر یا زود، ممکن است لازم باشد سروری ایجاد کنید که یک سرور HTTP مستقل باشد و از خدمات وب پشتیبانی کند. به عنوان مثال، ممکن است بخواهید یک سرور برنامه مبتنی بر SOAP برای یک برنامه n لایه ساخته شده با استفاده از دلفی ایجاد کنید.

معرفی

کمک آنلاین دلفی بسیار عالی است آموزش ترتیبیدر مورد نحوه ایجاد یک وب سرویس، سرور MIDAS (مدل COM، DCOM)، اما عملاً هیچ اطلاعاتی در مورد ایجاد یک برنامه مستقل N-tier MIDAS بر اساس پروتکل SOAP وجود ندارد.

قبلا توسط Dave Nottage منتشر شده بود. این مقاله ایده چگونگی ایجاد یک وب سرویس در دلفی 6 با پشتیبانی SOAP و توانایی انتشار رابط های SOAP از Datamodule را شرح می دهد، یعنی این مقاله به شما امکان می دهد یاد بگیرید که چگونه n-tier خود را ایجاد کنید. سیستم های MIDAS

دلفی 7 بورلند و کیت جدید ایندی از این قابلیت پشتیبانی داخلی دارند.

با این حال، با وجود پشتیبانی داخلی، این ویژگی مستند نیست.

پست های اخیر در کنفرانس شبکه Borland و جستجوی وب با استفاده از سرور Google به نویسندگان این امکان را داده است تا راهی برای تبدیل کد موجود از دلفی 6 به دلفی 7 ایجاد کنند. اما همه چیز زمان خود را دارد.

ایده اصلی

این مقاله اولین قسمت از یک مجموعه سه قسمتی است. مقررات اصلی را شرح می دهد. بخش دوم و سوم به برخی از مشکلات و راه های حل آنها اختصاص خواهد یافت. بیایید شروع به توصیف ایده اصلی کنیم.

• یک سرور HTTP مستقل باشید.
• از Indy به عنوان یک پلت فرم استفاده کنید.
• پشتیبانی از انتشار از طریق پروتکل SOAP.
• قادر به انتشار SOAP DataModules باشد که به شما امکان می دهد سرور n-tier خود را بر اساس SOAP/HTML ایجاد کنید.

سرور HTTP و SOAP

بسیاری از مردم Indy را می شناسند و قبلاً از مؤلفه های THTTPServer استفاده کرده اند. قرار دادن این کامپوننت در فرم درخواست آسان است، اما چگونه می‌توان آن را از SOAP پشتیبانی کرد؟ در دایرکتوری "C:Program FilesBorlandDelphi7SourceIndy" می توانید فایل IdHTTPWebBrokerBridge.pas را پیدا کنید. این دقیقا همان چیزی است که شما نیاز دارید.

این فایل بخشی از فایل اجرایی Indy نیست، بنابراین باید آن را به عنوان یک فایل پروژه استاندارد در پروژه فعلی خود قرار دهید. (برای کامپایل پروژه، به فایل IdCompilerDefines.inc نیز نیاز دارید.) این فایل ها باید در دایرکتوری پروژه فعلی کپی شوند. ممکن است تغییرات کد برای افزایش سرعت لازم باشد، بنابراین بهتر است این فایل ها را جدا از توزیع Indy نگه دارید.

در زیر پیاده سازی یک جزء جایگزین از THTTPServer، گسترش یافته برای پشتیبانی از بسته های SOAP، به نام TIdHTTPWebBrokerBridge را شرح می دهد. این ساختار کلاسی است که از TCustomHTTPServer به ارث می رسد و از اتصال درخواست اولیه پشتیبانی می کند.

از آنجایی که این کلاس از پالت قابل دسترسی نیست، هنگام اجرای کد خود باید آن را به عنوان یک شی معمولی تعریف کنید.

این شی را می توان دقیقاً به همان روشی که یک سرور THTTPS معمولی استفاده کرد، به استثنای آن دسته از ویژگی های اضافی که عملکرد با SOAP را امکان پذیر می کند.
با این حال، ابتدا به تهیه کد لازم می پردازیم.

وب بروکر و ایندی

برای کسانی که قبلا خدمات وب ایجاد کرده اند، می دانید که از آن استفاده می کنید وب بروکر. دلفی 7 مانند دلفی 6 از معماری WebBroker برای پشتیبانی از SOAP استفاده می کند.

بنابراین باید یک ماژول ایجاد کنید TWebModuleو سه جزء زیر را در آن قرار دهید: THTTPSoapDispatcher، THTTPSoapPascalInvoker و TWSDLHTMLPublish. همه آنها از برگه WebServices پالت مؤلفه در دسترس هستند. پس از پیوند SOAPDispatcher با SOAPPascalInvoker، فرم درخواست آماده است. نتیجه نهایی باید چیزی شبیه به چیزی باشد که در شکل زیر نشان داده شده است:

(ماژول uWebModule.pas)

بهتر است همه چیز را همانطور که هست رها کنید، زیرا نیازی به تغییر یا اجرای کد سفارشی برای این فرم نیست.

WebModule و Indy

بیایید به قسمت دیگر کد مورد نیاز برای پیاده سازی سرور HTTP برویم.

همانطور که می بینید، TIdHTTPWebBrokerBridge دارای یک متد RegisterWebModuleClass است که به شما امکان می دهد WebModule خود را ثبت کرده و در اختیار سرور قرار دهید.

بنابراین، پس از ایجاد شی سرور fServer، فقط باید کلاس fServer.RegisterWebModuleClass (TwmSOAPIndy) را فراخوانی کنید.

توجه داشته باشید.در یک پیاده سازی معمولی TIdHTTPWebBrokerBridge، هر بار که درخواستی دریافت می شود، یک شی TwmSOAPIndy ایجاد می شود. بدیهی است که این لازم نیست. بنابراین، کلاس را می توان برای ایجاد ایجاد دائمی تغییر داد از این شیتا زمانی که شی Server وجود دارد. توصیه می شود برای اطلاعات بیشتر به مستندات پیاده سازی کلاس مراجعه کنید.

آیا سرور آماده است؟

مقدمه ای بر ایندی

مقدمه ای بر ایندی
ارسال شده توسط Chad Z. Hower
صفحه اصلی: http://www.atozedsoftware.com
ترجمه: آناتولی پودگورتسکی
معرفی
من این مقاله را زمانی نوشتم نسخه فعلیایندی 8.0 بود. بسیاری از این مقاله در نسخه های آینده Indy قابل اجرا و بسیار مفید است. اگر این مقاله را دوست داشتید و می خواهید مقالات عمیق تری بخوانید، کتاب Indy in Depth را بررسی کنید.
ایندی در حالت مسدود کردن در حال اجرا است
ایندی از سوکت های مسدود کننده استفاده می کند. حالت مسدود کردن شبیه به خواندن و نوشتن فایل است. هنگام خواندن یا نوشتن داده ها، عملکرد تا زمانی که عملیات کامل نشود، کنترل را بر نمی گرداند. تفاوت کار با فایل‌ها این است که تماس ممکن است بیشتر طول بکشد، زیرا داده‌های درخواستی هنوز وجود ندارد، این بستگی به سرعت عملکرد شبکه یا مودم شما دارد.
برای مثال، یک متد به سادگی فراخوانی می شود و منتظر می ماند تا کنترل به نقطه تماس برگردد. اگر فراخوانی موفقیت آمیز بود، کنترل از متد برگردانده می شود، اگر خطایی رخ دهد، یک استثنا ایجاد می شود.
قفل کردن کشنده نیست
به دلیل حالت مسدود کردن، ما بارها توسط حریفان خود کتک خوردیم، اما حالت مسدود کردن، شیطان نیست.
این مشکل پس از انتقال Winsock به ویندوز ظاهر شد. در یونیکس، مشکل معمولاً با فورکینگ (مشابه چند رشته ای، اما با فرآیندهای جداگانه به جای نخ ها) حل می شد. کلاینت‌ها و دیمون‌های یونیکس باید فرآیندهایی را که باید اجرا می‌شد، فورک می‌کردند و از حالت مسدود کردن استفاده می‌کردند. Windows 3.x را نمی‌توان موازی کرد و از Threading زیادی پشتیبانی نمی‌کرد. استفاده از یک رابط مسدود کننده، رابط کاربری را مسدود کرده و برنامه ها را بی پاسخ می کند. بنابراین، حالت‌های غیر مسدود کننده به WinSock اضافه شد و به Windows 3.x با محدودیت‌هایش اجازه می‌دهد بدون مسدود کردن رشته اصلی و تنها برنامه از Winsock استفاده کند. این امر مستلزم برنامه نویسی متفاوتی بود و مایکروسافت و دیگران با شور و شوق حالت های مسدودسازی را برای پوشاندن کاستی های ویندوز 3.x مورد انتقاد قرار دادند.
سپس Win32 آمد که قادر به پشتیبانی از Multi-threading بود. اما در این زمان، مغز آنها از قبل به هم ریخته بود (یعنی توسعه دهندگان مسدود کردن سوکت ها را خلقت شیطان می دانستند)، و از قبل تغییر کاری که انجام داده بودند دشوار بود. بنابراین، اهانت به رژیم های مسدود کننده همچنان ادامه دارد.
در واقعیت، یونیکس فقط سوکت های مسدود کننده دارد. سوکت های مسدود نیز مزایای خود را دارند و برای چند رشته، امنیت و سایر جنبه ها بسیار بهتر هستند. برخی از برنامه های افزودنی برای سوکت های غیر مسدود کننده به یونیکس اضافه شده اند. با این حال، آنها بسیار متفاوت از ویندوز کار می کنند. آنها همچنین غیر استاندارد هستند و خیلی رایج نیستند. سوکت های مسدود کننده در یونیکس تقریباً در همه موارد استفاده می شوند و همچنان استفاده خواهند شد.
مزایای حالت مسدود کردن · برنامه ریزی آسان تر - برنامه نویسی حالت های مسدود کردن آسان تر است. همه کدهای کاربر می توانند در یک مکان باشند و به ترتیب طبیعی و متوالی اجرا شوند. · پورت کردن به یونیکس آسان تر - از آنجایی که یونیکس از سوکت های مسدود کننده استفاده می کند، نوشتن کد قابل حمل در این مورد آسان تر است. Indy از این واقعیت برای نوشتن کد یکنواخت استفاده می کند. · کار با نخ ها راحت تر است - از آنجایی که سوکت های مسدود کننده دنباله ای دارند که توسط وراثت به دست می آید، بنابراین استفاده از آنها در نخ ها بسیار آسان است.
معایب حالت مسدود کردن · رابط کاربری در کلاینت ها مسدود می شود - یک تماس سوکت مسدود کننده تا زمانی که کار خود را کامل نکرده باشد، کنترل را بر نمی گرداند. هنگامی که چنین تماسی در رشته اصلی برنامه برقرار می شود، برنامه نمی تواند پیام های کاربر را پردازش کند. این باعث می شود که رابط کاربری مسدود شود، ویندوز بازخوانی نشود، و هیچ پیام دیگری پردازش نشود تا زمانی که کنترل از سوکت مسدود کننده بازگردانده شود.
جزء TIdAntiFreeze
ایندی کامپوننت خاصی دارد که مشکل فریز کردن رابط کاربری را حل می کند. به سادگی یک مؤلفه TIdAntiFreeze را در هر جایی از برنامه خود اضافه کنید و می توانید تماس های مسدود کننده را بدون مسدود کردن رابط کاربری برقرار کنید.
TIdAntiFreeze بر روی یک تایمر داخلی خارج از پشته تماس اجرا می شود و با پایان یافتن مهلت، Application.ProcessMessages را فراخوانی می کند. تماس‌های خارجی به Indy همچنان مسدود هستند و بنابراین دقیقاً مانند بدون استفاده از مؤلفه TIdAntiFreeze کار می‌کنند. استفاده از TIdAntiFreeze به شما این امکان را می دهد که از تمام مزایای مسدود کردن سوکت ها، بدون هیچ یک از معایب بهره مند شوید.
رشته های کد (Threading)
با سوکت های مسدود کننده، تقریبا همیشه از جریان های کد استفاده می شود. سوکت های غیر مسدود کننده نیز می توانند از رشته ها استفاده کنند، اما این به مقداری نیاز دارد پردازش اضافیو مزایای آنها در این مورد در مقایسه با سوکت های مسدود کننده از بین می رود.
مزایای رشته ها · تنظیم اولویت ها - اولویت های رشته های جداگانه را می توان پیکربندی کرد. این اجازه می دهد تا وظایف فردی کم و بیش زمان CPU اختصاص یابد. · کپسوله سازی - هر اتصال می تواند شباهتی از یک رابط با اتصال دیگر داشته باشد. · امنیت - هر رشته می تواند ویژگی های امنیتی متفاوتی داشته باشد. · پردازنده های متعدد - مزیتی را در سیستم هایی با چندین پردازنده فراهم می کند. · بدون نیاز به سریال سازی - همزمانی کامل را فراهم می کند. بدون threading زیاد، همه درخواست ها باید در یک رشته پردازش شوند. بنابراین، هر کار باید به قطعات کوچک تقسیم شود تا بتواند به سرعت کار کند. در حالی که یک بلوک در حال اجرا است، بقیه مجبورند منتظر بمانند تا تمام شود. در پایان یک بلوک، بلوک بعدی اجرا می شود و به همین ترتیب. با multithreading، هر وظیفه را می توان به عنوان یک واحد برنامه ریزی کرد و سیستم عاملزمان را بین تمام وظایف تقسیم می کند.
موضوعات نظرسنجی
ایجاد و از بین بردن Thread ها بسیار نیازمند منابع است. این کار مخصوصاً برای سرورهایی که اتصالات کوتاه مدت دارند دشوار است. هر سرور یک رشته ایجاد می کند، برای مدت کوتاهی از آن استفاده می کند و سپس آن را از بین می برد. این منجر به ایجاد و حذف موضوعات بسیار مکرر می شود. نمونه ای از این یک وب سرور است. یک درخواست ارسال می شود و یک پاسخ ساده برگردانده می شود. هنگام استفاده از مرورگر، صدها اتصال و قطع ارتباط هنگام مشاهده هر وب سایتی ممکن است رخ دهد.
رشته های نظرسنجی می توانند این وضعیت را اصلاح کنند. به جای ایجاد و از بین بردن رشته‌ها در صورت تقاضا، رشته‌ها از فهرست رشته‌های استفاده نشده اما قبلاً ایجاد شده از استخر انتخاب می‌شوند. زمانی که نخی دیگر مورد نیاز نباشد، به جای از بین رفتن به استخر برگردانده می شود. رشته‌های موجود در استخر به‌عنوان بلااستفاده علامت‌گذاری می‌شوند و بنابراین زمان CPU را مصرف نمی‌کنند. برای بهبود بیشتر، نخ ها می توانند به صورت پویا با نیازهای فعلی سیستم سازگار شوند.
ایندی از نظرسنجی موضوعی پشتیبانی می کند. Thread Pool در Indy از طریق جزء TIdThreadMgrPool قابل دسترسی است.
تاپیک های زیاد
یک سرور با بارگذاری زیاد ممکن است به صدها یا حتی هزاران رشته نیاز داشته باشد. یک باور رایج وجود دارد که صدها و هزاران رشته می توانند سیستم شما را بکشند. این یک باور غلط است.
در اکثر سرورها، رشته ها منتظر داده می شوند. در حین انتظار برای مسدود کردن تماس، موضوع غیرفعال است. در سروری با 500 رشته، تنها 50 تا می توانند همزمان فعال باشند.
تعداد رشته هایی که روی سیستم شما در حال اجرا هستند ممکن است شما را شگفت زده کند. با حداقل تعداد سرورهای در حال اجرا و مشخص شده در حال اجرا برنامه های کاربردیسیستم من 333 رشته ایجاد کرده است، حتی با وجود 333 رشته، CPU تنها 1٪ بارگذاری شده است. به شدت بارگذاری شده است سرور IIS(سرور اطلاعات اینترنتی مایکروسافت) می تواند صدها و هزاران رشته ایجاد کند.
موضوعات و بخش های جهانی
با وجود رشته های متعدد، باید از یکپارچگی داده ها هنگام دسترسی به آن اطمینان حاصل کنید. این ممکن است برای برنامه نویسانی که با رشته ها کار نکرده اند دشوار باشد. اما به طور کلی اکثر سرورها نیازی به استفاده از داده های سراسری ندارند. اکثر سرورها عملکردهای ایزوله را انجام می دهند. هر رشته وظیفه جدا شده خود را انجام می دهد. بخش‌های خواندن/نوشتن جهانی یکی از ویژگی‌های بسیاری از برنامه‌های چند رشته‌ای هستند، اما برای سرورها معمولی نیستند.
روش شناسی ایندی
Indy با سایر اجزای Winsock که شما به آن ها عادت دارید متفاوت است. اگر با اجزای دیگر کار کرده اید، پس بهترین راه حلفراموش خواهد کرد که چگونه کار می کنند. بسیاری از اجزای دیگر از تماس های غیر مسدود کننده (ناهمزمان) استفاده می کنند و به صورت ناهمزمان کار می کنند. آنها باید به رویدادها واکنش نشان دهند، یک ماشین حالت ایجاد کنند و حلقه های انتظار مکرر را اجرا کنند.
به عنوان مثال، در مورد سایر مؤلفه‌ها، وقتی اتصالی را فراخوانی می‌کنید، باید منتظر بمانید تا رویداد اتصال رخ دهد یا در یک حلقه منتظر بمانید تا یک ویژگی نشان دهد که اتصال رخ داده است. با Indy می توانید متد Connect را فراخوانی کرده و منتظر بمانید تا برگردد. در صورت موفقیت آمیز بودن اتصال یا ایجاد استثنا در صورت وجود مشکل، بازپرداخت صادر می شود. بنابراین کار با ایندی بسیار شبیه کار با فایل ها است. Indy به شما این امکان را می دهد که به جای پخش کردن آن در رویدادهای مختلف، تمام کد خود را در یک مکان قرار دهید. علاوه بر این، Indy هنگام کار با نخ بسیار ساده و راحت است.
ایندی چقدر متفاوت است؟
نمای کلی · مسدود کردن تماس ها استفاده می شود · رویداد محور نیست - رویدادهایی وجود دارد، اما برای نیازهای اطلاعاتی استفاده می شوند و واقعاً مورد نیاز نیستند. ·طراحی شده برای Threads - Indy برای نخ طراحی شده است، اما می تواند بدون نخ استفاده شود. برنامه نویسی متوالی
بررسی دقیق
Indy نه تنها از مسدود کردن تماس ها (همگام) استفاده می کند، بلکه مانند این کار می کند. یک جلسه Indy معمولی به این شکل است:
با IndyClient شروع کنید
اتصال؛ تلاش كردن
// کارهای خود را اینجا انجام دهید
در نهایت قطع اتصال؛ پایان؛
پایان؛
با اجزای دیگر به شکل زیر است:
روش TFormMain.TestOnClick(فرستنده: TComponent);
شروع
با SocketComponent شروع کنید
اتصال؛ تلاش كردن
در حالی که متصل نیستید شروع کنید
اگر IsError سپس شروع کنید
سقط
پایان؛

OutData:= "داده برای ارسال";
در حالی که طول (OutData) > 0 شروع می شود
Application.ProcessMessages;
پایان؛
در نهایت قطع اتصال؛ پایان؛
پایان؛
پایان؛
روش TFormMain.OnConnectError;
شروع
IsError:= True;
پایان؛
روش TFormMain.OnRead.
var
i: عدد صحیح
شروع
i:= SocketComponent.Send(OutData);
OutData: = کپی (OutData، i + 1، MaxInt)؛
پایان؛
بسیاری از کامپوننت ها کار خیلی خوبی در جداسازی برنامه نویس از پشته انجام نمی دهند. بسیاری از مؤلفه ها، به جای اینکه کاربر را از پیچیدگی های پشته جدا کنند، به سادگی کاربر را به آن بسپارند یا یک پوشش روی پشته ارائه دهند.
راه خاص ایندی
ایندی از ابتدا به صورت چند رشته ای طراحی شده است. ساخت سرور و کلاینت در ایندی مشابه ساخت سرور و کلاینت در یونیکس است. برنامه های یونیکس معمولاً پشته را مستقیماً با لایه انتزاعی کم یا بدون لایه فراخوانی می کنند.
به طور معمول، سرورهای یونیکس یک یا چند فرآیند شنیداری دارند که درخواست‌های مشتری ورودی را نظارت می‌کنند. برای هر مشتری که نیاز به ارائه خدمات دارد، الف روند جدید. این امر برنامه نویسی را ساده می کند، هر فرآیند فقط برای یک مشتری. هر فرآیند در زمینه امنیتی خاص خود اجرا می شود که توسط فرآیند یا فرآیند گوش دادن بر اساس حقوق موجود، هویت یا موارد دیگر تنظیم می شود.
سرورهای Indy تقریباً به همین روش کار می کنند. ویندوز بر خلاف یونیکس نمی تواند پردازش ها را به خوبی تکثیر کند، اما با Thread ها به خوبی کار می کند. سرورهای Indy یک رشته مجزا برای هر اتصال کلاینت ایجاد می کنند.
سرورهای Indy یک رشته شنیداری را اختصاص می دهند که از رشته کد اصلی برنامه جدا است. رشته گوش دادن به درخواست های دریافتی از مشتریان گوش می دهد. برای هر مشتری که به آن پاسخ می دهد، یک موضوع جدید برای خدمت به مشتری ایجاد می شود. رویدادهای مربوطه سپس در زمینه سرویس دهی می شوند از این جریان.
بررسی مشتریان ایندی
ایندی برای ارائه سطح بسیار بالایی از انتزاع طراحی شده است. پیچیدگی و جزئیات پشته TCP/IP از برنامه نویس پنهان است. به طور معمول، یک جلسه مشتری معمولی در Indy به شکل زیر است:
با IndyClient شروع کنید
میزبان:= "zip.pbe.com"; // میزبان برای تماس
بندر:= 6000; // پورت برای فراخوانی سرور
اتصال؛ تلاش كردن
// کارهای خود را اینجا انجام دهید
در نهایت قطع اتصال؛ پایان؛
پایان؛
نمای کلی سرور ایندی
اجزای سرور Indy یک رشته شنیداری ایجاد می کند که از رشته کد اصلی برنامه جدا شده است. رشته گوش دادن به درخواست های دریافتی از مشتریان گوش می دهد. برای هر مشتری که به آن پاسخ می دهد، یک موضوع جدید برای خدمت به مشتری ایجاد می شود. رویدادهای مربوطه سپس در زمینه آن موضوع سرویس می شوند.

نمونه های عملی
مثال‌های زیر به شما کمک می‌کنند تا با کامپوننت‌ها شروع کنید آسان برای استفاده، اما به منظور نشان دادن نمونه های ساخته شده به عنوان برنامه های کاربردی ساده. برخی از پروژه ها برای نشان دادن موقعیت های مختلف ساخته شده اند. این نمونه ها به صورت فایل فشرده نیز برای دانلود در دسترس هستند.
توجه مترجم: لینک موجود در سایت کار نمی کند.
مثال 1 - تأیید کد پستی
پروژه اول تا حد امکان ساده ساخته شده است. جستجو بر اساس کد پستی، مشتری از سرور می پرسد که کد پستی مشخص شده متعلق به کدام شهر و ایالت است.
برای کسانی که خارج از ایالات متحده زندگی می کنند و نمی دانند کد پستی چیست، این یک کد پستی است که محل تحویل را نشان می دهد. کدهای پستی شامل 5 رقم است.
پروتکل
اولین قدم در ساخت سرور و کلاینت، توسعه یک پروتکل است. برای پروتکل های استاندارد، این توسط RFC مربوطه تعریف می شود. برای کد پستی، پروتکل زیر تعریف شده است.
بیشتر پروتکل های ارتباطی در آن کار می کنند حالت متنی. تبادل به این معنی است که یک فرمان و در پاسخ، وضعیت و احتمالاً داده ها منتقل می شود. پروتکل ها به تبادل محدود نمی شوند، اما همچنان از متن ساده استفاده می شود. پروتکل تعیین کد پستی نیز مبتنی بر متن است. متن ساده اشکال زدایی پروتکل ها را آسان می کند و به زبان های برنامه نویسی و سیستم عامل های مختلف اجازه می دهد تا با هم ارتباط برقرار کنند.
پس از اتصال، سرور پیام سلام ارسال می کند، سپس فرمان را می پذیرد. این دستور می تواند "ZipCode x" (جایی که x کد پستی است) یا "Quit" باشد. در پاسخ به دستور ZipCode، پاسخی در قالب یک خط با پاسخ یا ارسال می شود خط خالیاگر کد پیدا نشد دستور Quit باعث می شود که سرور اتصال را ببندد. سرور ممکن است چندین فرمان را قبل از ارسال فرمان Quit بپذیرد.
کد منبع سرور

واحد سرور اصلی؛

رابط

استفاده می کند

نوع

TformMain = کلاس (TForm)

IdTCPServer1: TIdTCPServer.

رویه FormCreate(فرستنده: TObject) ;

رویه FormDestroy(فرستنده: TObject) ;

رویه IdTCPServer1Connect(AThread: TIdPeerThread) ;

خصوصی

ZipCodeList: TStrings;

عمومی

پایان ؛

FormMain: TformMain;

پیاده سازی

(R*.DFM)

رویه TformMain.IdTCPServer1Connect (AThread: TIdPeerThread) ;

شروع

AThread.Connection .WriteLn ("Indy Zip Code Server Ready.") ;

پایان ؛

SCCommand: string ;

شروع

SCCommand:= ReadLn ;

پایان ؛

پایان ؛

پایان ؛

رویه TformMain.FormCreate (فرستنده: TObject ) ;

شروع

ZipCodeList:= TStringList.Create ;

ZipCodeList.LoadFromFile(ExtractFilePath(Application.EXEName) + "ZipCodes.dat");

پایان ؛

رویه TformMain.FormDestroy (فرستنده: TObject) ;

شروع

ZipCodeList.Free ;

پایان ؛

پایان.

تنها بخش‌های خاص Indy در پروژه عبارتند از مولفه IdTCPServer1، روش‌های IdTCPServer1Connect و IdTCPServer1Execute.
فرم شامل مولفه IdTCPServer1 از نوع TIdTCPServer است. ویژگی های زیر تغییر کرده اند: · Active = True - پس از شروع برنامه، سرور گوش می دهد. ·DefaultPort = 6000 - مقدار پورت برای این پروژه. سرور به درخواست های مشتری در این پورت گوش می دهد.
روش IdTCPServer1Execute با رویداد OnExecute سرور مرتبط است. رویداد OnExecute پس از پذیرفته شدن اتصال مشتری مطرح می شود. رویداد OnExecute با سایر رویدادهایی که می شناسید متفاوت است. OnExecute در زمینه یک رشته اجرا می شود. رویداد thread بالا می‌رود و آرگومان AThread به متد ارسال می‌شود. این مهم است زیرا چندین رویداد OneExecute را می توان همزمان اجرا کرد. این کار به این دلیل انجام می شود که سرور بتواند بدون ایجاد کامپوننت جدید کار کند. همچنین روش هایی وجود دارد که می توان آنها را در هنگام ساخت وراث نادیده گرفت.
رویداد OnConnect پس از پذیرش اتصال و ایجاد یک رشته برای آن فعال می شود. در این سرور از این برای ارسال پیام خوش آمدگویی به مشتری استفاده می شود. در صورت تمایل، این کار را می توان در رویداد OnExecute نیز انجام داد.
رویداد OnExecute می تواند چندین بار اجرا شود تا زمانی که اتصال قطع یا قطع شود. این نیاز به بررسی اتصال برای قطع یا از دست دادن در یک حلقه در یک رویداد را حذف می کند.
IdTCPServer1Execute از دو تابع اصلی ReadLn و WriteLn استفاده می کند. ReadLn یک رشته را از اتصال می خواند و WriteLn یک رشته را به اتصال می فرستد.
sCommand:= ReadLn;
کد بالا یک رشته از کلاینت گرفته و در متغیر رشته محلی sCommand قرار می دهد.

اگر SameText (sCommand، "QUIT") سپس شروع کنید

end other if SameText (Copy (sCommand, 1 , 8 ) , "ZipCode" ) سپس شروع کنید

WriteLn(ZipCodeList.Values[Copy(sCommand, 9, MaxInt)]);

پایان ؛

بعد، sCommand برای دستورات معتبر بررسی می شود.
اگر دستور "خروج" باشد، قطع ارتباط انجام می شود. پس از قطع ارتباط، خواندن و نوشتن مجاز نیست. پس از پایان رویداد، رشته شنیداری دیگر آن را فراخوانی نمی کند، بلکه موضوع را پاک می کند و اتصال را خاتمه می دهد.
اگر دستور "ZipCode" باشد، پارامتر بعد از دستور استخراج شده و جدول برای وجود شهر و ایالت اسکن می شود. سپس شهر و ایالت به مشتری ارسال می شود، یا در صورت عدم وجود یک رشته خالی ارسال می شود.
بعد، روش خارج می شود. سرور به محض رسیدن یک فرمان جدید، رویداد را مجدداً افزایش می دهد و به مشتری امکان می دهد چندین دستور را ارسال کند.
کد منبع مشتری

واحد ClientMain;

رابط

استفاده می کند

ویندوز، پیام‌ها، SysUtils، کلاس‌ها، گرافیک‌ها، کنترل‌ها، فرم‌ها، دیالوگ‌ها،

StdCtrls، ExtCtrls، IdAntiFreezeBase،

IdAntiFreeze، IdBaseComponent، IdComponent، IdTCPConnection، IdTCPClient.

نوع

TformMain = کلاس (TForm)

مشتری: TIdTCPClient;

IdAntiFreeze1: TIdAntiFreeze.

Panel1: TPanel;

Panel2: TPanel;

MemoInput: TMemo;

نتایج Lbox: TListBox;

Panel3: TPanel;

دکمه 1: TButton;

Button2: TButton;

Label1: TLabel;

رویه Button2Click(فرستنده: TObject) ;

رویه Button1Click(فرستنده: TObject) ;

خصوصی

عمومی

پایان ؛

FormMain: TformMain;

پیاده سازی

(R*.DFM)

رویه TformMain.Button2Click (فرستنده: TObject ) ;

شروع

MemoInput.Clear ;

LboxResults.Clear ;

پایان ؛

رویه TformMain.Button1Click (فرستنده: TObject ) ;

I: عدد صحیح

S: رشته ;

شروع

ButnLookup.Enabled := true; تلاش كردن

LboxResults.Clear ;

با مشتری شروع کنید

اتصال؛ تلاش كردن

LboxResults.Items.Add(ReadLn);

برای i:= 0 به memoInput.Lines .Count - 1 شروع می شود

WriteLn("ZipCode" + memoInput.Lines[i]);

LboxResults.Items.Add(memoInput.Lines[i]);

S:= ReadLn ;

اگر s = "" سپس شروع کنید

S:= "-- هیچ ورودی برای این کد پستی یافت نشد.";

پایان ؛

LboxResults.Items.Add(s);

LboxResults.Items.Add("");

پایان ؛

WriteLn ("خروج");

در نهایت قطع اتصال؛ پایان ؛

پایان ؛

در نهایت butnLookup.Enabled := true; پایان ؛

پایان ؛

پایان.

تنها بخش‌های خاص کامپوننت کلاینت، متد Button1Click است.
جزء Client از نوع TIdTCPClient است و روی فرم قرار می گیرد. ویژگی های زیر تغییر کرده اند: · Host = 127.0.0.1 - سرور در همان ماشینی قرار دارد که مشتری قرار دارد. ·پورت = 6000 - پورت سرور
متد Button1Click با رویداد OnClick مولفه Button1 مرتبط است. هنگامی که دکمه کلیک می شود، این روش فراخوانی می شود. بخش Indy این روش را می توان به موارد زیر کاهش داد: 1. اتصال به سرور (Connect;) 1. خواندن تبریک از سرور. 1. برای هر خط وارد شده توسط کاربر در TMemo: 1. ارسال درخواست به سرور (WriteLn("ZipCode" + memoInput.Lines[i]);) 1. خواندن پاسخ از سرور (s:= ReadLn; ) 1. ارسال دستور Quit (WriteLn("Quit");) 1.Disconnect (Disconnect;)
آزمایش کردن
این مثال تست شده است و با TCP/IP نصب شده کار می کند. می‌توانید آن را طوری تغییر دهید که از طریق یک شبکه از یک رایانه به رایانه دیگر کار کند. با راه اندازی سرور در رایانه دیگری و تغییر نام یا IP سرور در مشتری.
برای آزمایش پروژه ها، سرور را کامپایل و اجرا کنید. سپس کلاینت را کامپایل و اجرا کنید. کد پستی خود را در قسمت یادداشت وارد کنید و کلید جستجو را فشار دهید.
اشکال زدایی
اشکال زدایی پروتکل های متنی بسیار آسان است زیرا می توان آنها را با استفاده از Telnet آزمایش کرد. برای این کار کافی است پورت سرور را بدانید. سرور جستجوی کد پستی در پورت 6000 گوش می دهد.
سرور جستجوی کد پستی را دوباره راه اندازی کنید. سپس یک کنسول (به عنوان مثال یک پنجره Dos) را باز کنید. حالا وارد کنید:
telnet 127.0.0.1 6000
اکنون به سرور متصل هستید. برخی از سرورها نیز پیام خوش آمدگویی ارسال می کنند. بعضی ها این کار را نمی کنند. خطوطی را که وارد می کنید نخواهید دید. اکثر سرورها به منظور صرفه جویی در ترافیک، اکو انجام نمی دهند. با این حال، می توانید تنظیمات telnet را با تنظیم گزینه "Echo On" تغییر دهید. این کار در کلاینت های مختلف telnet به طور متفاوتی انجام می شود و برخی اصلاً این ویژگی را ندارند. حالا وارد کنید:
کد پستی 37642
پاسخ سرور را خواهید دید:
تپه کلیسا، TN
برای قطع ارتباط از سرور، وارد کنید:
ترک کردن
مثال 2 - دسترسی به پایگاه داده
این مثال سروری را شبیه‌سازی می‌کند که باید کارهای مسدودسازی غیر از تماس‌های سوکت را انجام دهد. بسیاری از سرورها مجبور به کار در چنین شرایطی هستند. سرورهایی که نیاز به دسترسی به پایگاه داده، فراخوانی رویه ها یا محاسبات خارجی دارند، اغلب نمی توانند این تماس ها را قطع کنند، زیرا آنها تماس های خارجی هستند یا به دلیل پیچیدگی آن. دسترسی به پایگاه داده را نمی توان به قطعات کوچک تقسیم کرد و توسعه دهنده باید منتظر پایان عملیات با پایگاه داده باشد. این یک ویژگی نه تنها برای فراخوانی پایگاه داده، بلکه همچنین سایر عملیات مانند فشرده سازی، محاسبات و سایر پردازش های مشابه است.
برای اهداف نمایشی، بیایید تصور کنیم که سرور یک تماس با پایگاه داده برقرار می کند که تکمیل آن 5 ثانیه طول می کشد. برای ساده‌تر کردن، اجازه دهید این کار را به سادگی با یک مکث انجام دهیم، به جای تماس واقعی، از تابع Sleep(5000) برای این کار استفاده کنید.
این مثال همچنین به جزئیات کمتری نسبت به مثال قبلی نیاز دارد زیرا بسیاری از مفاهیم هنوز درک نشده اند.
منبع

واحد اصلی;

رابط

استفاده می کند

ویندوز، پیام‌ها، SysUtils، کلاس‌ها، گرافیک‌ها، کنترل‌ها، فرم‌ها، دیالوگ‌ها،

IdBaseComponent، IdComponent، IdTCPServer.

نوع

TformMain = کلاس (TForm)

IdTCPServer1: TIdTCPServer.

رویه IdTCPServer1Execute (AThread: TIdPeerThread) ;

خصوصی

عمومی

پایان ؛

FormMain: TformMain;

پیاده سازی

(R*.DFM)

رویه TformMain.IdTCPServer1Execute (AThread: TIdPeerThread) ;

I: عدد صحیح

شروع

با AThread.Connection شروع می شود

WriteLn("سلام. سرور DB آماده است.");

I:= StrToIntDef(ReadLn, 0);

// Sleep جایگزین یک DB طولانی یا تماس های دیگر می شود

خواب (5000);

WriteLn(IntToStr(i * 7));

پایان ؛

پایان ؛

پایان.

از آنجا که رویداد Execute در زمینه یک رشته اتفاق می افتد، کد پردازش می تواند هر طولی داشته باشد. هر کلاینت تاپیک مخصوص به خود را دارد و دیگر کلاینت ها را مسدود نمی کند.
آزمایش کردن
برای تست سرور DB، آن را کامپایل و اجرا کنید. با استفاده از Telnet به پورت 6001 به آن متصل شوید. سرور با یک پیام خوشامدگویی پاسخ خواهد داد. شماره را وارد کنید سرور درخواست شما را "پردازش" می کند و در عرض 5 ثانیه پاسخ می دهد.

پروتکل UDP برای انتقال پیام های متنی کاملاً خوب است، یعنی می توانید چت های محلی و موارد مشابه را سازماندهی کنید. تصمیم گرفتم مثالی از ساده ترین کار با UDP در دلفی بزنم.

آموزش گام به گام:

مثال زدم اما ببخشید هر خطی را یادداشت نکردم چون... من هیچ چیز پیچیده ای نمی بینم و هر کسی می تواند آن را بفهمد.

در واقع، اگر چیزی نامشخص است، می توانید یک سوال از من بپرسید. و این هم کد واقعی:

استفاده می کند
ویندوز، پیام‌ها، SysUtils، انواع، کلاس‌ها، گرافیک‌ها، کنترل‌ها، فرم‌ها،
گفتگوها، StdCtrls، IdUDPServer، IdBaseComponent، IdComponent، IdUDPBase،
IdUDPClient، IdSocketHandle؛

نوع
TForm1 = کلاس (TForm)
IdUDPClient1: TIdUDPClient.
IdUDPServer1: TIdUDPServer.
دکمه 1: TButton;
Label1: TLabel;
فرآیند FormCreate(فرستنده: TObject);
procedure FormClose(فرستنده: TObject؛ var Action: TCloseAction);
رویه Button1Click(فرستنده: TObject);
روش IdUDPServer1UDPRead(AThread: TIdUDPListenerThread؛ AData: TBytes;
ABinding: TIdSocketHandle)؛
خصوصی
(اعلامیه خصوصی)
عمومی
(اعلامیه های عمومی)
پایان؛

var
Form1: TForm1;

($R *.dfm)
[b]//روال ارسال پیام
رویه TForm1.Button1Click(فرستنده: TObject);
شروع
تلاش كردن
IdUDPClient1.Active:= True;
IdUDPClient1.Host:= "localhost";
IdUDPClient1.Connect.
اگر IdUDPClient1.Connected سپس
شروع
IdUDPClient1.Send(TimeToStr(Time));
Label1.Caption:= "ok";
پایان؛
IdUDPClient1.Active:= نادرست;
بوق;بیپ;بیپ;
بجز
MessageDlg("مشکلی پیش آمد =(", mtError, , 0);
پایان؛
پایان؛
[ب]
//روشن خاموش. سرور UDP هنگام راه اندازی و بستن فرم
روش TForm1.FormClose(فرستنده: TObject; var Action: TCloseAction);
شروع
IdUDPServer1.Active:= نادرست;
پایان؛

روش TForm1.FormCreate(فرستنده: TObject);
شروع
IdUDPServer1.Active:= True;
پایان؛

[b]//رویه واکنش سرور هنگام دریافت داده
روش TForm1.IdUDPServer1UDPRead(AThread: TIdUDPListenerThread;
AData: TBytes; ABinding: TIdSocketHandle)؛
Var
i:عدد صحیح
s:String;
شروع
s:= "";
تلاش كردن
i:= 0;
در حالی که (AData[i] 0) انجام دهید
شروع
s:= s + chr(AData[i]);
i:= i + 1;
پایان؛
سرانجام
Label1.Caption:= s;
پایان؛
پایان؛