Úvod do Indy. Vývoj aplikací klient-server pomocí Indy v Delphi

Komponenty Indy používané v Delphi 6.

Kromě základních internetových služeb a protokolů existuje celá řada doplňkových služeb, jejichž možnosti často využívají internetoví vývojáři. Možnost zobrazení informací pomocí prohlížeče navíc není pro internetové aplikace vždy přijatelným řešením. V tomto případě je rozumné využít pro výměnu dat internetovou infrastrukturu a poskytovat zobrazení informací prostřednictvím složitějších klientských aplikací vyvinutých např. v Delphi.

Řekněme, že potřebujete implementovat specializovanou serverovou logiku, která není součástí standardních webových serverů. K vyřešení této třídy problémů obsahuje Delphi knihovnu Internet Direct (Indy) od Nevrona Designs (http://www.nevrona.com/Indy/). Tato knihovna, vyvinutá speciálně pro Borland Delphi, má již osm verzí, z nichž nejnovější je součástí nová verze Delphi. Sada komponent je rozdělena do tří skupin: klient (Indy Client), server (Indy Servers) a pomocný (Indy Misc).

Klienti Indy a Server Indy s

Většina komponent Indy Client a Indy Servers jsou páry odpovídající klientským a serverovým částem protokolů a služeb (s výjimkou určitých, zejména serverových, komponent, jako je TunnelMaster a TunnelSlave), a umožňují použití protokolů, jako je TCP/IP. , UDP, NNTP, SMTP, FTP, HTTP a také služby ECHO, FINGER, WHOIS atd.

Komponenty klienta Indy jsou zapsány pomocí soketů. Soket na straně klienta vyžaduje připojení k serveru. Pokud je spojení navázáno, klient a server si mohou začít vyměňovat zprávy. Tyto zprávy jsou různé povahy, ale obvykle k výměně dochází pomocí specifického protokolu (například HTTP)

TIdTCPClient a TIdTCPServer

Tyto komponenty se používají k podpoře jednoho z hlavních síťových protokolů - TCP (Transmission Control Protocol) a jsou také základními třídami pro komponenty TIdSMTP a TIdFTP. Třída TIdTCPServer má vlastnost ThreadMgr, která má výchozí hodnotu nula. Pokud je ThreadMgr nula, když je povolen TIdTCPServer, bude implicitně vytvořena třída TIdThreadMgrDeafault. Jinak se použije nainstalovaný správce procesů.

TIdUDPClient a TIdUDPServer

Tyto komponenty slouží k podpoře síťový protokol UDP (User Datagram Protocol) a jsou také základní třídy pro řadu dalších komponent Indy.

TIdChargenServer

Komponenta se používá ke generování náhodných symbolů, obvykle pro účely testování.

TIdDayTime a TIdDayTimeServer

Komponenty slouží k poskytování časové služby. Klient požádá a server oznámí aktuální datum a čas.

TIdDNSResolver

Jedná se o klientskou komponentu, která obsluhuje požadavky ze serveru DNS (Domain Name Service). Dotazy serveru DNS jsou navrženy tak, aby nahradily název počítače jeho IP adresou. TIdDNSResolver je potomkem třídy TIdUDPClient.

TidDICTServer

Komponenta serveru, která podporuje Dictionary Server Protocol (DICT), slovník na straně serveru založený na protokolu TCP, který umožňuje klientovi přístup ke slovníku přirozeného jazyka.

Server TidDISCARD

Komponenta serveru, která podporuje server záznamů. Nahrávky lze použít jako nástroj pro ladění a měření. Záznamová služba jednoduše předá jakákoli data tomu, kdo je ochoten je přijmout.

TI dEcho a TI dECHOServer

Komponenty jsou navrženy tak, aby poskytovaly službu odezvy, která se obvykle používá ke kontrole stavu sítě. Klient odešle textovou zprávu na server, server vrátí zprávu klientovi. Pokud je zpráva zkomolená, síť nefunguje správně.

TIdFinger a TIdFingerServer

Komponenty jsou navrženy tak, aby poskytovaly protokol, který umožňuje uživateli dotazovat se na data týkající se přítomnosti jiných uživatelů v systému. Některé servery takové požadavky klientů zpracovávají. Použití této dvojice komponent vám umožní obsluhovat požadavky klientů, které určují přítomnost dalších uživatelů v systému.

Komponenta obsahuje plnou podporu pro protokol přenosu souborů - FTP (File Transfer Protocol). Podporován je pasivní i aktivní přenos dat a také operace jako GET a PUT, mazání adresářů, získávání kvót, velikosti souborů a adresářů. TI dFTP používá k provozu třídu TIdSimpleServer. Když probíhá přenos souborů FTP, otevře se sekundární připojení TCP pro přenos dat a po přenosu dat se ukončí. Toto spojení se nazývá „datové spojení“, jedinečné pro každý přenášený soubor.

TIdGopher a TIdGopherServer

Tyto komponenty jsou navrženy tak, aby poskytovaly síťový protokol, který byl nahrazen Nedávno z WWW (svět Široká síť) HTTP protokol. Server, který implementuje tento protokol, poskytuje hierarchický systém podpory distribuovaného toku dokumentů. Příklad použití této dvojice komponent umístěných v adresáři demosindyGopherClient a demosindy GopherServer ukazuje, jak lze tento protokol použít k poskytování lokální síť informace o souborech umístěných ve vašem počítači, včetně uzavřených.

TIdHostNameServer

Komponenta serveru určená k předávání názvu místního serveru klientům.

TIdHTTP a TIdHTTPServer

Komponenty slouží k poskytování síťového protokolu HTTP (podporovány jsou verze 1.0 a 1.1, včetně operací GET, POST a HEAD). Kromě toho je poskytována podpora pro ověřování a používání proxy serverů. Serverová komponenta se používá k poskytování služeb jinému webovému serveru, který podporuje daný protokol. TIdHTTPServer usnadňuje implementaci funkcí, jako jsou soubory cookie, správa stavu atd.

TIdIcmpClient

Klientská komponenta navržená tak, aby poskytovala protokol ICMP (Internet Control Message Protocol), který se používá k provádění operací ping a trasování sítě.

Klientská komponenta navržená tak, aby poskytovala Post Office Protocol (POP), včetně podpory kódování a dekódování MIME a vícebajtového přenosu znaků.

Server TIDIMAP4

Serverová komponenta navržená pro podporu operací IMAP (Internet Message Access Protocol) na serveru. Protokol umožňuje vyhledávat zprávy E-mailem na serveru. Rozdíl mezi protokoly IMAP a POP je v tom, že protokol POP vyžaduje přídavná paměť k ukládání dat a protokol IMAP přistupuje k serveru místo ke klientskému počítači. IMAP4 byl vytvořen jako náhrada POP3, ale POP3 zůstává dodnes široce používaným standardem.

TidIRCServer

Komponenta serveru navržená pro podporu nejběžněji používaných servisních operací na internetu, běžně nazývaných chat. Komponenta poskytuje základní stavební bloky pro server IRC (Internet Relay Chat).

TIdMappedPortTCP

Serverová komponenta určená k vytváření mapovaných portů, které se často používají v proxy serverech. Metody této komponenty umožňují mapovat jeden port na druhý. Například port 80 by mohl být mapován na port 3000 a všechny požadavky na první port (port 80) by byly předány na druhý port (port 3000).

TIdNNTP a TIdNNTPServer

Tyto součásti jsou vyžadovány pro podporu protokolu NNTP (Network News Transfer Protocol) používaného v diskusních službách. Klientská komponenta zahrnuje podporu pro kódování a dekódování MIME, stejně jako podporu pro vícebajtové znaky a alternativní kódování. Serverová komponenta umožňuje vytvářet diskusní servery. Je důležité poznamenat, že TIdNNTPServer není plnohodnotný zpravodajský server, ale komponenta, která poskytuje základní funkce pro takový server.

TIdQOTD a TIdQOTDServer

Komponenty se používají k poskytování služby Quote of the Day. Klientská komponenta se připojí k instanci komponenty serveru, aby získala denní nabídku. Každá instance serveru obsahuje jedinečnou citační databázi.

Klientská komponenta navržená pro použití v aplikacích SMTP (Simple Mail Transfer Protocol), poskytující podporu pro ověřování, kódování a dekódování MIME a podporu vícebajtových znaků.

Klientská komponenta určená k poskytování SNTP (Simple Network Time Protocol) – časové služby. Lze jej použít pro připojení k jakékoli časové službě pro určení aktuálního data a času.

TIdSimpleServer

Serverová komponenta, která poskytuje odlehčený TCP server. Umožňuje organizovat spojení typu point-to-point. Používá se k vytváření serverů s jedním uživatelem, to znamená, že může obsluhovat pouze jedno připojení najednou. Na rozdíl od komponenty TIdTCPServer nevytváří sekundární procesy při čekání na požadavky od klientů a při zpracování těchto požadavků. Jinými slovy, pokud server obsluhuje požadavek od klienta a v tu chvíli jej kontaktuje jiný klient, aby se připojil, bude zablokován až do konce zpracování prvního požadavku.

TIdTelnet a TIdTelnetServer

Klientská komponenta se používá k organizaci vzdálených relací na jiném počítači, včetně vyjednávání konzoly a ověřování. Komunikační protokol předpokládá přítomnost osoby interaktivně interagující se serverem. Klientská komponenta nemá podporu zobrazení ani emulaci terminálu, ale jednoduše poskytuje připojení k serverové části. Typicky se serverový protokol TIdTelnetServer používá k organizaci vzdálených databází s textovým rozhraním pro interaktivní interakci s klienty.

TIdTime a TIdTimeServer

Klientská komponenta je alternativou ke komponentě TIdSNTP pro určování času. Je důležité si uvědomit, že formáty těchto dvou protokolů se liší. TIdTime je založen na formátu RFC 868 (vrací čas v interním standardu UNIX OS, provádí všechny potřebné konverze). Serverová komponenta funguje podobně jako DayTime server. Lze použít k implementaci časové služby na místní počítač. Není vyžadován žádný další kód, stačí vytvořit instanci TIdTimeServer, která vrátí čas vnitřních hodin serverového počítače.

TIdTrivialFTP a TIdTrivialFTPServer

Tyto komponenty jsou nezbytné pro organizaci jednoduchého protokolu pro přenos souborů. Klientská komponenta tohoto protokolu se používá k připojení k instanci odpovídající serverové komponenty. Protokol je určen pro privátní, odlehčené, lokální případy přenosu souborů, například v lokálních sítích nebo pro nahrání (nahrání) směrovacích tabulek do routerů. Vzhledem k oslabeným vlastnostem tohoto protokolu se jeho použití nedoporučuje při použití autentizačních algoritmů nebo jiných bezpečnostních mechanismů. Hlavním účelem tohoto protokolu je přenos souborů do hardwarového zařízení za účelem jeho úpravy.

TIdTunnelMaster a TIdTunnelSlave

Komponenty tunelu serveru se používají v proxy serverech k organizaci více logických připojení přes jeden fyzický (tunel). Tyto třídy lze použít k různým účelům, například k uspořádání tajného spojení přes netajné kanály.

TIdWhois a TIdWhoIsServer

Tato klientská komponenta se připojuje k libovolnému standardnímu serveru Whois a umožňuje vám získávat informace o doménách. Serverová komponenta poskytuje základní funkce NIC serveru.

Indy Různé

Stránka palety Indy Miscellaneous Components obsahuje BASE64, UUE, Quoted Printable a další běžné e-mailové komunikační formáty, kodéry (MD2, MD4 a MD5) pro kryptografické standardy používané k ukládání hesel a elektronické podpisy v nevratné (těžko dešifrovatelné) podobě, stejně jako mnoho dalších užitečných komponent a utilit často používaných při vývoji internetových aplikací.

TIdAntiFreeze

Vzhledem k blokově založeným algoritmům komponent Indy se často zdá, že se aplikace zasekne, zatímco připojení funguje. Chcete-li eliminovat použití sekundárních procesů (vlákna) při organizaci komunikace, aby se zabránilo zamrznutí aplikace, stačí umístit zadanou komponentu na formulář.

Komponenta funguje tak, že analyzuje požadavky ze zásobníku protokolu TCP/IP a během prodlevy, kdy jsou externí spojení blokována, odesílá zprávy aplikaci, což vytváří iluzi běžícího kódu. Protože komponenta ovlivňuje blokovaná připojení pouze pro hlavní proces, není použití TIdAntiFreeze v sekundárních procesech aplikace vyžadováno. Mějte na paměti, že komponenta TIdAntiFreeze zpomaluje připojení, protože hlavní proces je pravidelně přerušován kvůli zpracování zpráv. Z toho vyplývá, že je třeba dbát na to, aby vyvíjená aplikace nestrávila příliš mnoho času zpracováním zpráv, včetně OnClick, OnPaint, OnResize atd. Do jisté míry to lze ovládat prostřednictvím vlastností třídy TIdAntiFreeze. Použití této komponenty není povinné, ale umožňuje vyřešit problém synchronizace spojení s vizuálním rozhraním aplikace.

TIdDateTimeStamp

Třída pro provádění matematiky data a času související se skutečností, že internetové protokoly používají různé formáty data a času; klienti a servery se navíc mohou nacházet v různých časových pásmech.

TIDIPWatch

Je to komponenta založená na časovači, která neustále monitoruje změny IP adresy počítače. Události součásti nastanou, když je zjištěna změna. Tato komponenta se obvykle používá ke zjištění, zda je počítač připojen k internetu nebo jiné síti. Změna adresy IP v této situaci může nastat v důsledku přidělení adresy IP serverem DHCP (Dynamic Host Configuration Protocol) při připojování k nové síti.

TIdLogDebug

Účelem této komponenty je zachytit události jakékoli klientské nebo serverové komponenty a umístit záznam o události zadaný soubor. Tato komponenta je velmi užitečná pro ladění komponent Indy.

TIdMessage

Komponenta se používá v kombinaci s dalšími komponentami ke správnému dešifrování nebo kódování zpráv. Mohou to být komponenty POP, SMTP a NNTP. Třída podporuje šifrování a dešifrování MIME, vícebajtové znaky a kódování ISO.

TIdNetworkCalculator

Jedna z mála komponent Indy, kterou lze použít při vytváření aplikací. Síťovou kalkulačku lze použít k provádění výpočtů IP adres, včetně síťových masek, podsítí, tříd sítě atd.

TIdThreadMgrVýchozí

Komponenta standardně poskytuje řízení sekundárních procesů. Vytvoří se, když žádná komponenta Indy, která podporuje správu procesů, nemá definovanou instanci třídy TIdThreadManager. Komponenta poskytuje pouze základní schopnosti pro správu sekundárních procesů: jejich vytváření a ničení na vyžádání.

TIdThreadMgrPool

Pokročilejší komponenta správy procesů než TIdThreadMgrDefault, protože procesy spíše slučuje, než aby je na požádání vytvářela nebo ničila.

TIdVCard

VCard je elektronický ekvivalent vizitky a může obsahovat osobní údaje majitele a grafická data.

TIdIMFDecoder

Navrženo pro dekódování internetových zpráv. Je to potomek třídy TIdCoder, stejně jako všechny ostatní komponenty kodéru. Třída TIdCoder se dekóduje podle standardu ARPA internetového formátu textových zpráv RFS-822, navrženého v srpnu 1982, a standardu zpráv USENET RFC 1036, navrženého v prosinci 1987.

Komponenta rozšiřuje třídu TIdCoder tak, aby umožňovala detekci formátu RFS-822 podle kontextu záhlaví, poskytuje režim dešifrování při příjmu a šifrování a dešifrování MIME. Komponenta TIdIMFDecoder se používá ve třídě TIdMessageClient k dekódování přijatých a vysílaných zpráv.

TIdQuotedPrintableEncoder

QuotedPrintableEncoder umožňuje dešifrovat text v určeném formátu. Může sloužit jako samostatná součást se specifikovaným typem kódování, což umožňuje přenos zpráv obsahujících nový typ kódování.

Kódovač TIDBase64

Implementuje další šifrovací algoritmus, který umožňuje přenášet netisknutelné znaky.

TIdUUEncoder

Implementuje jeden z prvních šifrovacích algoritmů, kódování UU. Někdy se používá při odesílání článků do zpravodajské služby.

TIdXXEncoder

Tato metoda šifrování pravděpodobně nebude nikdy použita. V podstatě se jedná o stejné kódování UU, ale s jinou šifrovací tabulkou.

TIDCoderMD2

Komponenty s různými typy šifrovacího algoritmu MD (Message Digest). Všechny jsou založené na náhodném pořadí, jsou jednosměrné a nemají žádné dešifrovací algoritmy.

Komponenty protokolových klientů a serverů lze použít k vývoji serverových a klientských internetových aplikací společně se základními (ClientSocket, ServerSocket) nebo místo nich a dalšími komponentami z palety Internet a Fastnet. Komponenty Indy nepoužívají architekturu WebBroker, implementují nízkoúrovňovou podporu internetových protokolů a služeb přímo ve svém zdrojovém kódu (zdrojové kódy jsou součástí).

TIdConnectionInterceptOpenSSL a TIdServerInterceptOpenSSL

Protokol SSL - Secure Sockets Layer, který zajišťuje utajení a spolehlivost komunikace mezi dvěma aplikacemi, má dvě vrstvy. Na nízké úrovni vícevrstvého transportního protokolu (jako je TCP) je SSL záznamový protokol a používá se k zapouzdření různých protokolů vyšší úrovně. Výhodou SSL je, že jde o nezávislý aplikační protokol, ale nad rámec SSL lze použít i protokol vyšší úrovně.

SSL poskytuje zabezpečení komunikace, které má tři hlavní funkce: poskytování důvěrného připojení; šifrování s veřejný klíč(slouží k potvrzení pravosti adresáta); podpora spolehlivosti přenosu dat.

K šifrování dat se používá symetrická kryptografie (např. DES, RC4 atd.).
Digitální podpis je poskytován pomocí asymetrického šifrování veřejným klíčem (například RSA, DSS atd.).
Spolehlivost komunikace, transport zpráv zahrnuje kontrolu integrity zprávy pomocí korekčních kódů MAC, bezpečných hashovacích funkcí (např. SHA, MD5 atd.) pomocí výpočtů MAC.

V kombinaci s HTTP a ověřováním serveru poskytuje SSL potřebné funkcešifrování a dále udržuje navázané spojení, dvojitou kontrolu pravosti webového serveru atd. Je důležité pochopit, že SSL chrání pouze komunikaci během přenosu dat a nenahrazuje jiné bezpečnostní mechanismy.

Komponenty TIdConnectionInterceptOpenSSL a TIdServerInterceptOpenSSL poskytují připojení na straně klienta i na straně serveru pomocí protokolu SSL. Je třeba poznamenat, že komponenty TIdConnectionInterceptOpenSSL a TIdServerInterceptOpenSSL jsou dostupné pouze v Delphi 6, nikoli v Kylixu. To je způsobeno složitostí protokolu, který je v případě implementace Windows založen na funkcích operačního systému.

Příklady použití komponent Indy lze nalézt v adresářích /Delphi6/Demos/Indy. Celkem obsahuje knihovna Indy ve verzi 8.0 69 komponent. Uvádí se, že ve verzi 9.0 bude zadaná knihovna obsahovat 86 komponent. Všechny komponenty jsou sjednoceny a obsaženy v Delphi 6 i Kylixu, což umožňuje jejich použití pro vývoj multiplatformních aplikací. Všechny komponenty Indy podporují multithreading.

Komponenty Indy implementují téměř všechny funkce nalezené v komponentách Internet a Fastnet, jak je jasně uvedeno v tabulce.

	Fastn a komponenty	Indy komponenty	Účel komponent
1	TserverSocket, TClientSocket	TIdTCPserverSocket, TIdTCPClientSocket	Interakce mezi dvěma počítači (klient a server) pomocí protokolu TCP/IP
2	TNMDayTime	TIdDayTime, TIdDayTimeServer	Dotaz na server na aktuální čas
3	TNMEcho	TIdEcho, TIdEchoServer	Používá se ke komunikaci s odpovědním serverem
4	TNMFinger	TIdFinger, TIdFingerServer	Slouží k získání informací o uživateli z internetového vyhledávacího serveru
5	TNMFTP	TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer	Zajistěte přenos souborů pomocí protokolu FTP
6	TNMHTTP	TIdHTTP, TIdHTTPServer	Pro výměnu dat použijte protokol HTTP
7	TNMMsgServ, TNMMsg		Používá se k jednoduchému přenosu textové zprávy z klienta na server
8	TNMNNTP	TIdNNTP, TIdNNTPServer	Podporuje výměnu dat s news serverem
9	TNMPOP3	TIDPOP3	Používá se pro příjem e-mailů z poštovního serveru pomocí protokolu POP3
10	TNMSMTP	TIdSMTP	Používá se k odesílání e-mailů přes poštovní server Internet
11	TNMStrm, TNMStrmServ		Přenáší binární data zapsaná do proudu pomocí protokolu TCP/IP
12	TNMUDP	TIdUDP, TIdUDPServer	Přenos dat pomocí protokolu UDP
13	TpowerSock, TNMGeneralServer		Třídy zapouzdřené komponentami, které jsou základem pro psaní vašich vlastních klientů (Powersock) a serverů (NMGeneralServer)
14	Procesor TNMUU	TIdUUEncoder, TIdUUDecoder	Proveďte překódování binární soubory do formátu MIME nebo UUENCODE
15	TNMURL		Převádí řetězce do formátu HTML a provádí zpětnou konverzi

Výjimkou jsou třídy jako TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, které buď implementují zastaralé protokoly, nebo mají funkcionalitu implementovanou ve velké skupině alternativních tříd.

Na rozdíl od svých předchůdců – komponent Internet a Fastnet, však Indy obsahuje bohatší serverové komponenty a komponenty pro překódování a šifrování dat a také podporu autentizace (paleta Indy Misc). Jak je patrné z výše uvedené tabulky, hlavní protokoly a služby jsou poskytovány nejen klientskými, ale také serverovými komponentami. Jedná se o časové služby, služby odezvy, získávání uživatelských informací, dále protokoly HTTP, NNTP, UDP a dokonce i nejjednodušší verzi FTP.

Některé příklady použití komponent Indy

V komponentách Indy obsažených v Delphi je IP adresa definována ve vlastnosti Host, obvykle pouze v klientských aplikacích. Komponenty hostované na serveru mají metody, které vám umožňují spustit nebo zastavit dotazování odpovídajícího portu – například změna vlastnosti Active komponenty IdTCPServer spustí nebo zastaví dotazování odpovídajícího portu. Jakmile je navázáno spojení mezi klientem a serverem, může začít přenos dat.

Komponenty Indy kladou velký důraz na bezpečnost a spolehlivost při práci s daty. Například komponenta IdTCPClient má metody Connect a Disconnect. Pomocí programovací techniky, jako je níže uvedený kód, ze strany klienta:

S TCPClient začněte Connect; zkuste lstMain.Items.Add(ReadLn); nakonec Odpojit; konec; konec;

a pomocí vlastnosti Connection předané jako parametr instanci AThread třídy TIdPeerThread ze strany serveru:

S AThread.Connection začněte WriteLn("Dobrý den ze serveru Basic Indy Server."); Odpojit; konec;

můžete počítat buď s normálním provedením připojení, nebo se správným zpracováním chyb.

Všimněte si metod ReadLn a WriteLn odpovídajících tříd – podobají se standardním I/O příkazům Pascalu. To je daň za unixovou programovací techniku, kde se většina systémových operací provádí čtením a zápisem do odpovídajících souborů.

Stejně jako komponenty Fastnet mají třídy komponent Indy události, které lze použít k zajištění správy událostí. Můžete například zařídit, aby se zpráva zobrazila ve formuláři při připojení ke klientovi:

Procedure TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Obsluhující klient ]"; konec;

Indy poskytuje komponenty, které implementují protokoly s klientskými a serverovými částmi, které jsou jedinečné pro tuto knihovnu. Komponenty TIdGopherServer a TIdGopher díky metodám GetExtendedMenu, GetFile, GetMenu, GetTextFile na straně klienta a ReturnGopherItem, SendDirectoryEntry na straně serveru pomáhají prohlížet soubory. různé typy, včetně těch, které jsou označeny jako skryté, a také adresářů na vzdálený počítač(podobné tomu, co dělá příkaz dir *.* operační systém MS-DOS).

Pomocí komponent IdSMTP a IdMessage můžete snadno vytvořit vlastní webovou aplikaci, která umí odesílat poštu pomocí protokolu SMTP.

V tomto případě je třída IdMessage (jedna z 23 komponent na stránce Indy Misc) zodpovědná za generování zprávy, která vyplývá z jejího názvu, a IdSMTP je za organizaci spojení s poštovním serverem.

Technologie používaná v Indy využívá zamykání operací čtení a zápisu. Jakákoli operace Connect použitá v Indy čeká na dokončení připojení. Při práci s klientskými komponentami Indy obvykle musíte provést následující:

požádat o připojení k serveru;
zadávat požadavky na čtení a zápis na server (v závislosti na typu serveru se krok provede jednou nebo se mnohokrát opakuje);
ukončete připojení k serveru a odpojte se.

Komponenty Indy jsou navrženy tak, aby poskytovaly ultra vysokou úroveň abstrakce. Složitosti a podrobnosti zásobníku TCP/IP jsou před programátorem skryty, aby se mohl soustředit na daný úkol.

Následující malý příklad ukazuje typickou relaci client bean:

S IndyClient začněte Host:= "zip.pbe.com"; // Hostitel, který má volat Port:= 6000; // Port pro volání serveru na Connect; zkuste // Váš kód se dostane sem konečně Disconnect; konec; konec;

V tomto příkladu, i když není navázáno připojení k serveru, bude připojení řádně ukončeno kvůli použití příkazu try-finally.

Serverové komponenty Indy popisují různé modely serverů, které lze použít v závislosti na vašich potřebách a protokolu, který používáte.

TIdTCPServer je nejběžněji používaná serverová komponenta, která vytváří sekundární proces nezávislý na hlavním aplikačním procesu. Vytvořený proces čeká na příchozí požadavky od potenciální klienty. Pro každého klienta, na jehož požadavek reaguje, je vytvořen samostatný sekundární proces. Události, ke kterým dojde během procesu údržby, souvisí s kontextem odpovídajících procesů.

Jinými slovy, pro každé připojení klienta používá třída TIdTCPServer jedinečné sekundární vlákno voláním obslužné rutiny události OnExecute daného vlákna. Formálním parametrem metody OnExecute je odkaz na instanci třídy Athread odpovídající vytvořenému vláknu. Vlastnost Connection této třídy je odkazem na třídu TIdTCPConnection, jejíž instance je vytvořena pro zpracování požadavku klienta. TIdTCPConnection podporuje čtení a zápis přes připojení, stejně jako vytvoření a ukončení komunikační relace.

Protokol UDP funguje bez předchozího navázání spojení se serverem (každý odeslaný paket je nezávislou sadou dat a není součástí větší relace nebo spojení). Zatímco TIdTCPServer vytváří samostatná vlákna pro každé připojení, TIdUDPServer používá hlavní vlákno nebo jediné sekundární vlákno, které zpracovává všechny požadavky protokolu UDP. Když je TIdUDPServer aktivní, vytvoří se vlákno, které naslouchá příchozím paketům UDP. Pro každý přijatý paket je vyvolána událost OnUDPRead buď v hlavním vláknu, nebo v kontextu naslouchajícího vlákna, v závislosti na hodnotě vlastnosti ThreadedEvent. Když je ThreadedEvent vyhodnocena jako False, dojde k události v hlavním vláknu, jinak se vyskytuje v naslouchajícím vláknu. Během zpracovávání události jsou ostatní operace serveru blokovány. Proto je důležité zajistit, aby procedury OnUDPRead běžely co nejrychleji.

Pokud potřebujete vytvořit novou klientskou aplikaci pro existující server pomocí existujícího protokolu, vaším úkolem je pouze vyvinout a ladit klientskou aplikaci. Když však musíme vyvíjet klientské i serverové aplikace pomocí stávajícího nebo nového protokolu, stojíme před klasickým problémem „slepice a vejce“. Kde začít s programováním - z klienta nebo ze serveru?

Je zřejmé, že klient i server musí být nakonec vytvořeny. U mnoha aplikací, zejména těch, které používají textový protokol (jako je HTTP), je snazší začít sestavovat aplikaci návrhem serveru. A pro ladění existuje pohodlný klient, který již existuje. Toto je aplikace konzoly Telnet, která je k dispozici v systémech Windows i UNIX.

Pokud napíšete konzolu příkaz telnet 127.0.0.1 80 s IP adresou místního počítače a číslem portu 80, který je standardně používán webovými servery, pak aplikace odpoví textem znázorněným na Obr. 6, v případě OS Windows 2000 a IIS 5.0.

K vytvoření nejjednoduššího serveru pomocí komponent Indy potřebujete:

Pokud potřebujete navrhnout server, který bude nejen správně informovat své klienty o ztrátě spojení, ale také jim poskytne informace o chybových situacích, ke kterým došlo, použijte místo try-finally příkaz try-except - např. zobrazeno v následujícím příkladu:

Procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: řetězec; začněte s AThread.Connection zkuste zkusit s:= ReadLn; // Zde proveďte úlohu serveru // pokud není vyvolána žádná výjimka, // zapište odpověď serveru WriteLn(s); kromě e: Výjimka do begin WriteLn(e.Message); end; //on end; //zkus kromě nakonec Disconnect; end; end;

Tento malý příklad ukazuje kroky k vytvoření jednoduchého textového serveru a také způsob jeho ladění.

Výše popsaný server je typickým příkladem organizace moderní distribuované výpočetní techniky.

Funkce vytváření vícevrstvých aplikací

V poslední době se k uspokojení požadavků klientů stále více používá více serverů. Server tohoto typu poté, co přijal požadavek klienta a částečně jej připravil k dalšímu zpracování, kontaktuje jiný server a odešle mu transformovaný požadavek nebo požadavky. Server druhé vrstvy může zase komunikovat s jinými servery. Můžeme tedy mluvit o vícevrstvé serverové architektuře.

Dále vytvoříme datový server, jehož účelem je vracet data z databáze. Tento server však nečte ani nezapisuje soubory databáze přímo. Místo toho komunikuje s databázovým serverem při hledání dat požadovaných klientem.

Začneme tedy vyvíjet aplikaci s třívrstvou architekturou. Chcete-li vytvořit databázový server pomocí komponent Indy, potřebujete:

Vytvořte nový projekt.
Položit hlavní formulář instance projektu komponenty TIdTCPServer z palety Indy Servers.
Nastavte vlastnost DefaultPort instance třídy TIdTCPServer1 na 6001 (doporučuje se přiřazovat velké hodnoty, abyste se vyhnuli duplikaci čísel portů v různých aplikacích) a nastavte vlastnost Active na true.
Přidejte do projektu nový modul výběrem Soubor | Nový | Data Module a umístěte na něj instance komponent SQLConnection a SQLDataSet ze záložky dbExpress na paletě komponent.
Nastavte vlastnost ConnectionName třídy SQLConnection na IBLocal a LoginPrompt na hodnotu False. Pokud jste nenakonfigurovali IBLocal v databázi zaměstnanec.gdb, dokončete nejprve tento postup.

Úvod do Indy

Úvod do Indy
Zveřejnil to Chad Z. Hower
Domovská stránka: http://www.atozedsoftware.com
Překlad: Anatoly Podgoretsky
úvod
Tento článek jsem napsal, když současná verze byl Indy 8.0. Velká část tohoto článku je použitelná a velmi užitečná v budoucích verzích Indy. Pokud se vám tento článek líbil a chcete si přečíst podrobnější články, pak se podívejte na knihu Indy in Depth.
Indy běží v režimu blokování
Indy používá blokovací zásuvky. Režim blokování je podobný jako čtení a zápis souboru. Při čtení nebo zápisu dat funkce nevrátí řízení, dokud není operace dokončena. Rozdíl oproti práci se soubory je v tom, že volání může trvat déle, protože požadovaná data ještě neexistují, záleží na rychlosti, kterou vaše síť nebo modem pracuje.
Například je jednoduše zavolána metoda a čeká, dokud se řízení nevrátí do volacího bodu. Pokud bylo volání úspěšné, bude vrácena kontrola z metody, pokud dojde k chybě, bude vyvolána výjimka.
Uzamčení není fatální
Kvůli režimu blokování jsme byli našimi soupeři mnohokrát poraženi, ale režim blokování není ďábel.
Problém se objevil po portování Winsock do Windows. V Unixu byl problém typicky řešen forkingem (podobně jako multi-threading, ale s oddělenými procesy místo vláken). Unixoví klienti a démoni museli forkovat procesy, které by měly běžet, a používat režim blokování. Windows 3.x nemohl být paralelizován a nepodporoval mnoho vláken. Použití blokovacího rozhraní zmrazilo uživatelské rozhraní a programy přestaly reagovat. Proto byly do WinSock přidány neblokující režimy, které umožňují Windows 3.x s jeho omezeními používat Winsock bez blokování hlavního a jediného vlákna programu. To vyžadovalo jiné programování a Microsoft a další vášnivě haněli režimy blokování, aby zakryli nedostatky Windows 3.x.
Pak přišel Win32, který byl schopen podporovat multi-threading. Ale tou dobou už byly jejich mozky zamotané (to znamená, že vývojáři považovali blokování zásuvek za výtvor ďábla) a už bylo těžké změnit to, co udělali. Očerňování blokujících režimů proto pokračuje.
Ve skutečnosti má Unix pouze blokovací zásuvky. Blokovací sockety mají také své výhody a jsou mnohem lepší pro multi-threading, bezpečnost a další aspekty. Do Unixu byla přidána některá rozšíření pro neblokující sockety. Fungují však úplně jinak než ve Windows. Jsou také nestandardní a nepříliš obvyklé. Blokovací zásuvky v Unixu se používají téměř ve všech případech a budou se používat i nadále.
Výhody režimu blokování · Snadnější programování - Režimy blokování se snadněji programují. Veškerý uživatelský kód může být na jednom místě a spuštěn v přirozeném, sekvenčním pořadí. ·Snazší port na Unix – Vzhledem k tomu, že Unix používá blokovací sockety, je v tomto případě jednodušší psát přenosný kód. Indy tuto skutečnost využívá k psaní jednotného kódu. ·Je pohodlnější pracovat s vlákny - Vzhledem k tomu, že blokovací sockety mají sekvenci získanou dědičností, takže se velmi snadno používají ve vláknech.
Nevýhody blokovacího režimu · Uživatelské rozhraní zamrzá v klientech – volání blokujícího soketu nevrátí řízení, dokud nedokončí svůj úkol. Když je takové volání provedeno v hlavním vláknu aplikace, aplikace nemůže zpracovat uživatelské zprávy. To způsobí, že uživatelské rozhraní zamrzne, okna se neobnoví a nebudou zpracovány žádné další zprávy, dokud nebude vrácen ovládací prvek z blokovacího soketu.
Komponenta TIdAntiFreeze
Indy má speciální součást, která řeší problém zamrzání uživatelské rozhraní. Jednoduše přidejte jednu komponentu TIdAntiFreeze kamkoli do vaší aplikace a můžete blokovat hovory bez zmrazení uživatelského rozhraní.
TIdAntiFreeze běží na interním časovači mimo zásobník volání a volá Application.ProcessMessages, když vyprší časový limit. Externí volání do Indy jsou nadále blokována, a proto fungují úplně stejně jako bez použití komponenty TIdAntiFreeze. Použití TIdAntiFreeze vám umožní získat všechny výhody blokování zásuvek bez jakýchkoli nevýhod.
Vlákna kódu (Threading)
S blokováním soketů se téměř vždy používají proudy kódu. Neblokující sokety mohou také používat vlákna, ale to vyžaduje nějaké dodatečné zpracování a jejich výhody se v tomto případě oproti blokovacím zásuvkám ztrácejí.
Výhody vláken · Nastavení priorit - Priority jednotlivých vláken lze konfigurovat. To umožňuje jednotlivým úlohám přidělovat více či méně času CPU. ·Zapouzdření - Každé připojení může obsahovat určitou podobu rozhraní s jiným připojením. ·Zabezpečení – Každé vlákno může mít různé bezpečnostní atributy. ·Více procesorů – poskytuje výhodu na systémech s více procesory. · Není potřeba serializace - poskytuje plnou souběžnost. Bez velkého podprocesu musí být všechny požadavky zpracovány v jednom vláknu. Každý úkol je proto nutné rozdělit na malé kousky, aby mohl rychle fungovat. Zatímco jeden blok běží, všichni ostatní jsou nuceni čekat na jeho dokončení. Na konci jednoho bloku se provede další a tak dále. Díky multithreadingu lze každou úlohu naprogramovat jako jednu jednotku a operační systém rozděluje čas mezi všechny úlohy.
Vlákna ankety
Vytváření a ničení vláken je velmi náročné na zdroje. To je obzvláště obtížný úkol pro servery, které mají připojení s krátkou životností. Každý server vytvoří vlákno, použije ho na krátkou dobu a poté ho zničí. Výsledkem je velmi časté vytváření a odstraňování vláken. Příkladem toho je webový server. Odešle se jeden požadavek a vrátí se jednoduchá odpověď. Při používání prohlížeče může při prohlížení jakékoli webové stránky dojít ke stovkám připojení a odpojení.
Vlákna dotazování mohou tuto situaci napravit. Namísto vytváření a rušení vláken na vyžádání se vlákna vybírají ze seznamu nepoužívaných, ale již vytvořených vláken z fondu. Když vlákno již není potřeba, vrátí se do fondu namísto zničení. Vlákna ve fondu jsou označena jako nepoužívaná, a proto nespotřebovávají čas procesoru. Pro ještě větší zlepšení se vlákna mohou dynamicky přizpůsobovat aktuálním potřebám systému.
Indy podporuje dotazování vláken. Fond vláken v Indy je přístupný prostřednictvím komponenty TIdThreadMgrPool.
Spousta vláken
Silně zatížený server může vyžadovat stovky nebo dokonce tisíce vláken. Existuje obecný názor, že stovky a tisíce vláken mohou zabít váš systém. To je falešná víra.
Na většině serverů vlákna čekají na data. Během čekání na blokovací hovor je vlákno neaktivní. Na serveru s 500 vlákny může být aktivních pouze 50 současně.
Počet vláken, která běží na vašem systému, vás možná překvapí. S minimálním počtem běžících serverů a zadaným spuštěné aplikace můj systém má vytvořeno 333 vláken, i při 333 vláknech je CPU zatíženo pouze na 1 %. Silně naložené server IIS(Microsoft Internet Information Server) může vytvořit stovky a tisíce vláken.
Vlákna a globální sekce
S více vlákny musíte zajistit integritu dat při přístupu k nim. To může být obtížné pro programátory, kteří nepracovali s vlákny. Obecně však většina serverů nepotřebuje používat globální data. Většina serverů provádí izolované funkce. Každé vlákno provádí svůj vlastní izolovaný úkol. Globální sekce pro čtení/zápis jsou funkcí mnoha vícevláknových aplikací, ale nejsou typické pro servery.
Metodologie Indy
Indy se liší od ostatních komponent Winsock, na které jste zvyklí. Pokud jste pracovali s jinými součástmi, pak nejlepší řešení zapomene, jak fungují. Mnoho dalších komponent používá neblokující (asynchronní) volání a funguje asynchronně. Potřebují reagovat na události, vytvořit stavový automat a provádět časté čekací smyčky.
Například u jiných komponent, když zavoláte připojení, musíte buď počkat, až dojde k události připojení, nebo čekat ve smyčce na vlastnost, která označí, že k připojení došlo. S Indy můžete zavolat metodu Connect a počkat, až se vrátí. Vrácení peněz bude vydáno, pokud je připojení úspěšné, nebo je vznesena výjimka, pokud dojde k problému. Práce s Indy je tedy velmi podobná práci se soubory. Indy vám umožňuje umístit veškerý kód na jedno místo, místo toho, abyste jej šířili do různých událostí. Indy je navíc velmi jednoduchý a nejpohodlnější při práci s nitěmi.
Jak moc se liší Indy?
Stručný přehled · Používá se blokování hovorů · Není orientováno na události - existují události, ale používají se pro informační potřeby a nejsou ve skutečnosti vyžadovány. ·Navrženo pro závity - Indy je určeno pro závity, ale může být použito bez závitů. Sekvenční programování
Podrobná recenze
Indy nejen používá blokování hovorů (synchronní), ale také funguje takto. Typická Indy session vypadá takto:
s IndyClient začít
Připojit; Snaž se
// Udělejte si své věci zde
nakonec Odpojit; konec;
konec;
S ostatními komponenty to vypadá takto:
procedure TFormMain.TestOnClick(Sender: TComponent);
začít
se SocketComponent začít
Připojit; Snaž se
když není připojeno, začněte
if IsError pak začněte
Přerušit;
konec;

OutData:= "Data k odeslání";
while length(OutData) > 0 do begin
Application.ProcessMessages;
konec;
nakonec Odpojit; konec;
konec;
konec;
procedura TFormMain.OnConnectError;
začít
IsError:= True;
konec;
procedura TFormMain.OnRead;
var
i: celé číslo;
začít
i:= SocketComponent.Send(OutData);
OutData:= Copy(OutData, i + 1, MaxInt);
konec;
Mnoho komponent neodvádí příliš dobrou práci při izolování programátoru od zásobníku. Mnoho komponent namísto toho, aby uživatele izolovalo od složitosti stohu, jednoduše to nechá na uživateli nebo poskytne obal přes stoh.
Indy zvláštním způsobem
Indy je od základu navržen jako vícevláknový. Vytváření serverů a klientů v Indy je podobné jako vytváření serverů a klientů v Unixu. Unixové aplikace obvykle volají zásobník přímo s malou nebo žádnou abstrakční vrstvou.
Unixové servery mají obvykle jeden nebo více naslouchacích procesů, které monitorují příchozí požadavky klientů. Pro každého klienta, který potřebuje obsloužit, a nový proces. Díky tomu je programování jednoduché, každý proces pouze pro jednoho klienta. Každý proces běží ve svém vlastním kontextu zabezpečení, který je nastaven naslouchajícím procesem nebo procesem na základě existujících práv, identity nebo jiných věcí.
Indy servery fungují v podstatě stejným způsobem. Windows na rozdíl od Unixu neumí dobře násobit procesy, ale funguje dobře s vlákny. Servery Indy vytvářejí samostatné vlákno pro každé připojení klienta.
Servery Indy přiřadí naslouchající vlákno, které je oddělené od hlavního vlákna programu. Naslouchající vlákno naslouchá příchozím požadavkům od klientů. Pro každého klienta, na kterého reaguje, se vytvoří nové vlákno, které bude sloužit klientovi. Relevantní události jsou pak obsluhovány v kontextu tohoto proudu.
Zákaznická recenze Indy
Indy je navržen tak, aby poskytoval velmi vysokou úroveň abstrakce. Složitost a podrobnosti zásobníku TCP/IP jsou programátorovi skryty. Typická klientská relace v Indy obvykle vypadá takto:
s IndyClient začít
Host:= "zip.pbe.com"; // Hostitel pro volání
Port:= 6000; // Port pro volání serveru
Připojit; Snaž se
// Udělejte si své věci zde
nakonec Odpojit; konec;
konec;
Přehled serveru Indy
Komponenty serveru Indy vytvářejí naslouchající vlákno, které je izolované od hlavního vlákna programového kódu. Naslouchající vlákno naslouchá příchozím požadavkům od klientů. Pro každého klienta, na kterého reaguje, se vytvoří nové vlákno, které bude sloužit klientovi. Odpovídající události jsou pak obsluhovány v kontextu tohoto vlákna.

Praktické příklady
Následující příklady by vám měly pomoci začít s komponentami pro snadné použití, ale za účelem demonstrování příkladů vyrobených jako jednoduché aplikace. Některé projekty jsou vytvořeny proto, aby demonstrovaly různé situace. Tyto příklady jsou také k dispozici ke stažení jako soubory zip.
Poznámka od překladatele: odkaz na webu nefunguje.
Příklad 1 – Ověření PSČ
První projekt je co nejjednodušší. Při vyhledávání podle PSČ se klient zeptá serveru, kterému městu a státu zadané PSČ patří.
Pro ty, kteří žijí mimo USA a nevědí, co je PSČ, je to poštovní směrovací číslo, které označuje místo doručení. Poštovní směrovací čísla se skládají z 5 číslic.
Protokol
Prvním krokem při budování serveru a klienta je vývoj protokolu. U standardních protokolů je to definováno odpovídajícím RFC. Pro poštovní směrovací číslo je protokol definován níže.
Většina komunikačních protokolů pracuje v textový režim. Výměna znamená, že je přenášen příkaz a jako odpověď stav a případně data. Protokoly nejsou omezeny na výměnu, ale stále se používá prostý text. Protokol pro určení PSČ je rovněž textový. Prostý text usnadňuje ladění protokolů a umožňuje komunikaci mezi různými programovacími jazyky a operačními systémy.
Po připojení server odešle zprávu ahoj a poté příkaz přijme. Tento příkaz může být "ZipCode x" (kde x je PSČ) nebo "Quit". V reakci na příkaz ZipCode je odeslána odpověď ve formě jednoho řádku s odpovědí resp prázdný řádek pokud kód není nalezen. Příkaz Quit způsobí, že server uzavře připojení. Před odesláním příkazu Quit může server přijmout několik příkazů.
Zdrojový kód serveru

jednotka ServerMain;

rozhraní

používá

typ

TformMain = třída(TForm)

IdTCPServer1: TIdTCPServer;

procedure FormCreate(Sender: TObject ) ;

procedure FormDestroy(Sender: TObject ) ;

procedura IdTCPServer1Connect(AThread: TIdPeerThread) ;

soukromé

ZipCodeList: TStrings;

veřejnost

konec ;

FormMain: TformMain;

implementace

(R*.DFM)

procedure TformMain.IdTCPServer1Connect (AThread: TIdPeerThread) ;

začít

AThread.Connection .WriteLn ( "Indy server PSČ připraven." ) ;

konec ;

SCPříkaz: string ;

začít

SCPříkaz:= ReadLn ;

konec ;

procedure TformMain.FormCreate (Sender: TObject ) ;

začít

ZipCodeList:= TStringList.Create ;

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

konec ;

procedure TformMain.FormDestroy (Sender: TObject ) ;

začít

ZipCodeList.Free ;

konec ;

konec.

Jediné části projektu specifické pro Indy jsou komponenta IdTCPServer1, metody IdTCPServer1Connect a IdTCPServer1Execute.
Formulář obsahuje komponentu IdTCPServer1 typu TIdTCPServer. Následující vlastnosti byly změněny: ·Active = True - Po spuštění aplikace server naslouchá. ·DefaultPort = 6000 - Hodnota portu pro tento projekt. Server naslouchá požadavkům klientů na tomto portu.
Metoda IdTCPServer1Execute je přidružena k události OnExecute serveru. Událost OnExecute je vyvolána po přijetí připojení klienta. Událost OnExecute se liší od ostatních událostí, které znáte. OnExecute běží v kontextu vlákna. Je vyvolána událost vlákna a je jí přidělen argument AThread předaný metodě. To je důležité, protože více událostí OnExecute lze spustit současně. To se provádí tak, aby server mohl pracovat bez vytváření nové komponenty. Existují také metody, které lze při konstrukci dědiců přepsat.
Událost OnConnect se spustí poté, co bylo připojení přijato a bylo pro něj vytvořeno vlákno. V tento server to se používá k odeslání uvítací zprávy klientovi. V případě potřeby to lze provést také v události OnExecute.
Událost OnExecute může být vyvolána vícekrát, dokud není připojení odpojeno nebo ztraceno. To eliminuje potřebu kontrolovat spojení na odpojení nebo ztrátu ve smyčce v rámci události.
IdTCPServer1Execute používá dvě základní funkce, ReadLn a WriteLn. ReadLn přečte řetězec z připojení a WriteLn odešle řetězec připojení.
sCommand:= ReadLn;
Výše uvedený kód vezme řetězec od klienta a umístí jej do místní proměnné řetězce sCommand.

pokud SameText (sCommand, "QUIT" ), pak začněte

end else if SameText (Copy (sCommand, 1, 8) , "ZipCode"), pak začít

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

konec ;

Dále je sCommand zkontrolován na platné příkazy.
Pokud je příkaz "Quit", pak se provede odpojení. Po odpojení není povoleno žádné čtení ani zápis. Po skončení události ji naslouchající vlákno již nevolá, ale vlákno vymaže a ukončí spojení.
Pokud je příkaz "ZipCode", pak je parametr po příkazu extrahován a tabulka je naskenována na přítomnost města a státu. Město a stát jsou poté předány klientovi, nebo pokud neexistuje žádná shoda, je předán prázdný řetězec.
Dále se metoda ukončí. Server znovu vyvolá událost, jakmile dorazí nový příkaz, což klientovi umožní odeslat více příkazů.
Zdrojový kód klienta

jednotka ClientMain;

rozhraní

používá

Windows, Zprávy, SysUtils, Třídy, Grafika, Ovládací prvky, Formuláře, Dialogy,

StdCtrls, ExtCtrls, IdAntiFreezeBase,

IdAntiFreeze, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient;

typ

TformMain = třída(TForm)

Klient: TIDTCPClient;

IdAntiFreeze1: TIdAntiFreeze;

Panel1: TPanel;

Panel2: TPanel;

MemoInput: TMemo;

LboxResults: TListBox;

Panel3: TPanel;

Tlačítko1: TButton;

Tlačítko2: TButton;

Label1: TLabel;

procedure Button2Click(Sender: TObject ) ;

procedure Button1Click(Sender: TObject ) ;

soukromé

veřejnost

konec ;

FormMain: TformMain;

implementace

(R*.DFM)

procedure TformMain.Button2Click (Sender: TObject ) ;

začít

MemoInput.Clear ;

LboxResults.Clear ;

konec ;

procedure TformMain.Button1Click (Sender: TObject ) ;

I: celé číslo;

S: řetězec ;

začít

ButnLookup.Enabled := true ; Snaž se

LboxResults.Clear ;

s klientem začít

Připojit; Snaž se

LboxResults.Items.Add(ReadLn);

for i:= 0 to memoInput.Lines .Count - 1 nezačíná

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

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

S:= ReadLn ;

pokud s = "" pak začněte

S:= "-- Pro toto PSČ nebyl nalezen žádný záznam.";

konec ;

LboxResults.Items.Add(s);

LboxResults.Items.Add("");

konec ;

WriteLn("Quit");

nakonec Odpojit; konec ;

konec ;

konečně butnLookup.Enabled := true ; konec ;

konec ;

konec.

Jedinými částmi specifickými pro klientskou komponentu je metoda Button1Click.
Klientská komponenta je typu TIdTCPClient a je umístěna na formuláři. Následující vlastnosti byly změněny: ·Host = 127.0.0.1 - Server je umístěn na stejném počítači jako klient. ·Port = 6000 – Port serveru
Metoda Button1Click je spojena s událostí OnClick komponenty Button1. Po kliknutí na tlačítko se tato metoda zavolá. Část Indy této metody lze zredukovat na následující: 1.Připojit se k serveru (Connect;) 1.Přečíst pozdrav ze serveru. 1. Pro každý řádek zadaný uživatelem v TMemo: 1. Odeslání požadavku na server (WriteLn("ZipCode " + memoInput.Lines[i]);) 1. Načtení odpovědi ze serveru (s:= ReadLn; ) 1. Odeslání příkazu Quit (WriteLn("Quit");) 1.Odpojit (Disconnect;)
Testování
Tento příklad byl testován a funguje s nainstalovaným TCP/IP. Můžete jej změnit tak, aby fungoval přes síť z jednoho počítače do druhého. Spuštěním serveru na jiném počítači a změnou názvu nebo IP serveru na klientovi.
Chcete-li otestovat projekty, zkompilujte a spusťte server. Poté zkompilujte a spusťte klienta. Zadejte své poštovní směrovací číslo do pole poznámky a stiskněte vyhledávací tlačítko.
Ladění
Textové protokoly lze velmi snadno ladit, protože je lze testovat pomocí Telnetu. K tomu stačí znát port serveru. Server pro vyhledávání PSČ naslouchá na portu 6000.
Znovu spusťte server pro vyhledávání PSČ. Poté otevřete konzolu (např. okno Dos). Nyní zadejte:
telnet 127.0.0.1 6000
Nyní jste připojeni k serveru. Některé servery také posílají uvítací zprávu. Někteří ne. Zadané řádky neuvidíte. Většina serverů neodpovídá, aby šetřila provoz. Nastavení telnetu však můžete změnit nastavením možnosti „Echo On“. V různých klientech telnetu se to dělá jinak a někteří tuto funkci nemají vůbec. Nyní zadejte:
PSČ 37642
Uvidíte odpověď serveru:
CHERCH HILL, TN
Chcete-li se odpojit od serveru, zadejte:
přestat
Příklad 2 - přístup k databázi
Tento příklad emuluje server, který musí provádět blokovací úlohy jiné než volání soketu. Mnoho serverů je nuceno pracovat v takových podmínkách. Servery, které potřebují přístup k databázi, volání externích procedur nebo výpočtů, často nemohou tato volání přerušit, protože se jedná o externí volání nebo kvůli jejich složitosti. Přístup k databázi nelze rozdělit na malé kousky a vývojář musí počkat na ukončení operace s databází. To je vlastnost nejen databázových volání, ale i dalších operací, jako je komprese, výpočty a další zpracování stejného druhu.
Pro demonstrační účely si představme, že server provede volání databáze, jehož dokončení trvá 5 sekund. Pro zjednodušení to udělejme jednoduše s pauzou, místo skutečného volání k tomu použijte funkci Sleep(5000).
Tento příklad také vyžaduje méně podrobností než předchozí příklad, protože mnoho pojmů ještě není pochopeno.
Zdroj

hlavní jednotka;

rozhraní

používá

Windows, Zprávy, SysUtils, Třídy, Grafika, Ovládací prvky, Formuláře, Dialogy,

IdBaseComponent, IdComponent, IdTCPServer;

typ

TformMain = třída(TForm)

IdTCPServer1: TIdTCPServer;

procedura IdTCPServer1Execute(AThread: TIdPeerThread) ;

soukromé

veřejnost

konec ;

FormMain: TformMain;

implementace

(R*.DFM)

procedure TformMain.IdTCPServer1Execute (AThread: TIdPeerThread) ;

I: celé číslo;

začít

s AThread.Connection začít

WriteLn("Dobrý den. DB server připraven.");

I:= StrToIntDef(ReadLn, 0);

// Spánek je nahrazen dlouhým DB nebo jiným voláním

Spánek(5000);

WriteLn(IntToStr(i * 7));

konec ;

konec.

Protože k události Execute dochází v kontextu vlákna, může mít kód zpracování libovolnou délku. Každý klient má své vlastní vlákno a neblokuje ostatní klienty.
Testování
Chcete-li otestovat DB server, zkompilujte jej a spusťte. Připojte se k němu pomocí Telnetu na port 6001. Server odpoví uvítací zprávou. Vložte číslo. Server váš požadavek „zpracuje“ a odpoví do 5 sekund.

Komponenty Indy používané v Delphi 6.

Řekněme, že potřebujete implementovat specializovanou serverovou logiku, která není součástí standardních webových serverů. K vyřešení této třídy problémů obsahuje Delphi knihovnu Internet Direct (Indy) od Nevrona Designs (http://www.nevrona.com/Indy/). Tato knihovna, vyvinutá speciálně pro Borland Delphi, má již osm verzí, z nichž nejnovější je součástí nové verze Delphi. Sada komponent je rozdělena do tří skupin: klient (Indy Client), server (Indy Servers) a pomocný (Indy Misc).

Indy klienti a Indy servery

TIdTCPClient a TIdTCPServer

TIdUDPClient a TIdUDPServer

Tyto komponenty se používají k podpoře síťového protokolu UDP (User Datagram Protocol) a jsou také základními třídami pro řadu dalších komponent Indy.

TIdChargenServer

Komponenta se používá ke generování náhodných symbolů, obvykle pro účely testování.

TIdDayTime a TIdDayTimeServer

Komponenty slouží k poskytování časové služby. Klient požádá a server oznámí aktuální datum a čas.

TIdDNSResolver

TidDICTServer

Server TidDISCARD

TI dEcho a TI dECHOServer

TIdFinger a TIdFingerServer

TIdFTP

Komponenta obsahuje plnou podporu pro protokol přenosu souborů - FTP (File Transfer Protocol). Podporován je pasivní i aktivní přenos dat a také operace jako GET a PUT, mazání adresářů, získávání kvót, velikosti souborů a adresářů. TI dFTP používá k provozu třídu TIdSimpleServer. Když probíhá přenos souborů FTP, otevře se sekundární připojení TCP pro přenos dat a po přenosu dat se ukončí. Toto připojení se nazývá „datové spojení“, které je jedinečné pro každý přenášený soubor.

TIdGopher a TIdGopherServer

Tyto komponenty jsou navrženy tak, aby poskytovaly síťový protokol, který byl nedávno nahrazen z WWW (World Wide Web) protokolem HTTP. Server, který implementuje tento protokol, poskytuje hierarchický systém podpory distribuovaného toku dokumentů. Příklad použití této dvojice komponent, umístěných v adresářích \demos\indy\GopherClient a \demos\indy\GopherServer, ukazuje, jak pomocí tohoto protokolu můžete v místní síti poskytovat informace o souborech umístěných na vašem počítači, včetně uzavřených .

TIdHostNameServer

Komponenta serveru určená k předávání názvu místního serveru klientům.

TIdHTTP a TIdHTTPServer

TIdIcmpClient

Klientská komponenta navržená tak, aby poskytovala protokol ICMP (Internet Control Message Protocol), který se používá k provádění operací ping a trasování sítě.

TIDPOP3

Klientská komponenta navržená tak, aby poskytovala Post Office Protocol (POP), včetně podpory kódování a dekódování MIME a vícebajtového přenosu znaků.

Server TIDIMAP4

Serverová komponenta navržená pro podporu operací IMAP (Internet Message Access Protocol) na serveru. Protokol umožňuje vyhledávat e-mailové zprávy na serveru. Rozdíl mezi protokoly IMAP a POP spočívá v tom, že protokol POP vyžaduje další paměť pro ukládání dat a protokol IMAP přistupuje k serveru místo ke klientskému počítači. IMAP4 byl vytvořen jako náhrada POP3, ale POP3 zůstává dodnes široce používaným standardem.

TidIRCServer

TIdMappedPortTCP

TIdNNTP a TIdNNTPServer

TIdQOTD a TIdQOTDServer

TIdSMTP

TIdSNTP

TIdSimpleServer

TIdTelnet a TIdTelnetServer

TIdTime a TIdTimeServer

Klientská komponenta je alternativou ke komponentě TIdSNTP pro určování času. Je důležité si uvědomit, že formáty těchto dvou protokolů se liší. TIdTime je založen na formátu RFC 868 (vrací čas v interním standardu UNIX OS, provádí všechny potřebné konverze). Serverová komponenta funguje podobně jako DayTime server. Lze použít k implementaci časové služby na místním počítači. Není vyžadován žádný další kód, stačí vytvořit instanci TIdTimeServer, která vrátí čas vnitřních hodin serverového počítače.

TIdTrivialFTP a TIdTrivialFTPServer

TIdTunnelMaster a TIdTunnelSlave

TIdWhois a TIdWhoIsServer

Tato klientská komponenta se připojuje k libovolnému standardnímu serveru Whois a umožňuje vám získávat informace o doménách. Serverová komponenta poskytuje základní funkce NIC serveru.

Indy Různé

Stránka Indy Miscellaneous Components zahrnuje BASE64, UUE, Quoted Printable a další běžné e-mailové komunikační formáty, kodéry (MD2, MD4 a MD5) pro kryptografické standardy používané k ukládání hesel a elektronických podpisů v nevratné (obtížně dešifrovatelné) podobě, jakož i mnoho dalších užitečných komponent a utilit často používaných při vývoji internetových aplikací.

TIdAntiFreeze

TIdDateTimeStamp

TIDIPWatch

TIdLogDebug

Účelem této komponenty je zachytit události jakékoli klientské nebo serverové komponenty a umístit záznam o události do určeného souboru. Tato komponenta je velmi užitečná pro ladění komponent Indy.

TIdMessage

TIdNetworkCalculator

TIdThreadMgrVýchozí

TIdThreadMgrPool

Pokročilejší komponenta správy procesů než TIdThreadMgrDefault, protože procesy spíše slučuje, než aby je na požádání vytvářela nebo ničila.

TIdVCard

VCard je elektronický ekvivalent vizitky a může obsahovat osobní údaje majitele a grafická data.

TIdIMFDecoder

TIdQuotedPrintableEncoder

Kódovač TIDBase64

Implementuje další šifrovací algoritmus, který umožňuje přenášet netisknutelné znaky.

TIdUUEncoder

Implementuje jeden z prvních šifrovacích algoritmů, kódování UU. Někdy se používá při odesílání článků do zpravodajské služby.

TIdXXEncoder

Tato metoda šifrování pravděpodobně nebude nikdy použita. V podstatě se jedná o stejné kódování UU, ale s jinou šifrovací tabulkou.

TIDCoderMD2

Komponenty s různými typy šifrovacího algoritmu MD (Message Digest). Všechny jsou založené na náhodném pořadí, jsou jednosměrné a nemají žádné dešifrovací algoritmy.

TIdConnectionInterceptOpenSSL a TIdServerInterceptOpenSSL

SSL poskytuje zabezpečení komunikace, které má tři hlavní funkce: poskytování důvěrného připojení; šifrování veřejným klíčem (slouží k potvrzení identity příjemce); podpora spolehlivosti přenosu dat.

K šifrování dat se používá symetrická kryptografie (např. DES, RC4 atd.).
Digitální podpis je poskytován pomocí asymetrického šifrování veřejným klíčem (například RSA, DSS atd.).
Spolehlivost komunikace, transport zpráv zahrnuje kontrolu integrity zprávy pomocí korekčních kódů MAC, bezpečných hashovacích funkcí (např. SHA, MD5 atd.) pomocí výpočtů MAC.

V kombinaci s HTTP a autentizací serveru poskytuje SSL nezbytné šifrovací funkce a dále udržuje navázané spojení křížovou kontrolou identity webového serveru atd. Je důležité pochopit, že SSL chrání pouze komunikaci během přenosu dat a nenahrazuje jiné bezpečnostní mechanismy.

Komponenty Indy implementují téměř všechny funkce nalezené v komponentách Internet a Fastnet, jak je jasně uvedeno v tabulce.

	Fastn a komponenty	Indy komponenty	Účel komponent
1	TserverSocket, TClientSocket	TIdTCPserverSocket, TIdTCPClientSocket	Interakce mezi dvěma počítači (klient a server) pomocí protokolu TCP/IP
2	TNMDayTime	TIdDayTime, TIdDayTimeServer	Dotaz na server na aktuální čas
3	TNMEcho	TIdEcho, TIdEchoServer	Používá se ke komunikaci s odpovědním serverem
4	TNMFinger	TIdFinger, TIdFingerServer	Slouží k získání informací o uživateli z internetového vyhledávacího serveru
5	TNMFTP	TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer	Zajistěte přenos souborů pomocí protokolu FTP
6	TNMHTTP	TIdHTTP, TIdHTTPServer	Pro výměnu dat použijte protokol HTTP
7	TNMMsgServ, TNMMsg		Používá se k přenosu jednoduchých textových zpráv z klienta na server
8	TNMNNTP	TIdNNTP, TIdNNTPServer	Podporuje výměnu dat s news serverem
9	TNMPOP3	TIDPOP3	Používá se pro příjem e-mailů z poštovního serveru pomocí protokolu POP3
10	TNMSMTP	TIdSMTP	Používá se k odesílání e-mailů přes internetový poštovní server
11	TNMStrm, TNMStrmServ		Přenáší binární data zapsaná do proudu pomocí protokolu TCP/IP
12	TNMUDP	TIdUDP, TIdUDPServer	Přenos dat pomocí protokolu UDP
13	TpowerSock, TNMGeneralServer		Třídy zapouzdřené komponentami, které jsou základem pro psaní vašich vlastních klientů (Powersock) a serverů (NMGeneralServer)
14	Procesor TNMUU	TIdUUEncoder, TIdUUDecoder	Převádí binární soubory do formátu MIME nebo UUENCODE
15	TNMURL		Převádí řetězce do formátu HTML a provádí zpětnou konverzi

Některé příklady použití komponent Indy

s TCPClient do begin Connect; zkuste lstMain.Items.Add(ReadLn); nakonec Odpojit; konec; konec;

a pomocí vlastnosti Connection předané jako parametr instanci AThread třídy TIdPeerThread ze strany serveru:

s AThread.Connection do begin WriteLn("Dobrý den ze serveru Basic Indy Server."); Odpojit; konec;

můžete počítat buď s normálním provedením připojení, nebo se správným zpracováním chyb.

procedure TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Obsluhující klient ]"; konec;

Indy poskytuje komponenty, které implementují protokoly s klientskými a serverovými částmi, které jsou jedinečné pro tuto knihovnu. Komponenty TIdGopherServer a TIdGopher díky metodám GetExtendedMenu, GetFile, GetMenu, GetTextFile na straně klienta a ReturnGopherItem, SendDirectoryEntry na straně serveru pomáhají prohlížet soubory různých typů, včetně těch označených jako skryté, a také adresáře na vzdálený počítač (podobně jako příkaz dir *.* v operačním systému MS-DOS).

Pomocí komponent IdSMTP a IdMessage můžete snadno vytvořit vlastní webovou aplikaci, která umí odesílat poštu pomocí protokolu SMTP.

požádat o připojení k serveru;
zadávat požadavky na čtení a zápis na server (v závislosti na typu serveru se krok provede jednou nebo se mnohokrát opakuje);
ukončete připojení k serveru a odpojte se.

Následující malý příklad ukazuje typickou relaci client bean:

s IndyClient do begin Host:= "zip.pbe.com"; // Hostitel, který má volat Port:= 6000; // Port pro volání serveru na Connect; zkuste // Váš kód se dostane sem konečně Disconnect; konec; konec;

V tomto příkladu, i když není navázáno připojení k serveru, bude připojení řádně ukončeno kvůli použití příkazu try-finally.

Serverové komponenty Indy popisují různé modely serverů, které lze použít v závislosti na vašich potřebách a protokolu, který používáte.

TIdTCPServer je nejběžněji používaná serverová komponenta, která vytváří sekundární proces nezávislý na hlavním aplikačním procesu. Vytvořený proces čeká na příchozí požadavky od potenciálních klientů. Pro každého klienta, na jehož požadavek reaguje, je vytvořen samostatný sekundární proces. Události, ke kterým dojde během procesu údržby, souvisí s kontextem odpovídajících procesů.

Pokud potřebujete vytvořit novou klientskou aplikaci pro existující server pomocí existujícího protokolu, vaším úkolem je pouze vyvinout a ladit klientskou aplikaci. Když však musíme vyvíjet klientské i serverové aplikace pomocí stávajícího nebo nového protokolu, čelíme klasickému problému „slepice a vejce“. Kde začít s programováním - z klienta nebo ze serveru?

Pokud zadáte konzolový příkaz telnet 127.0.0.1 80 s IP adresou místního počítače a číslem portu 80, který je standardně používán webovými servery, aplikace odpoví textem znázorněným na Obr. 6, v případě OS Windows 2000 a IIS 5.0.

K vytvoření nejjednoduššího serveru pomocí komponent Indy potřebujete:

procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: řetězec; začněte s AThread.Connection zkuste zkusit s:= ReadLn; // Zde proveďte úlohu serveru // pokud není vyvolána žádná výjimka, // zapište odpověď serveru WriteLn(s); kromě e: Výjimka do begin WriteLn(e.Message); end; //on end; //zkus kromě nakonec Disconnect; end; end;

Tento malý příklad ukazuje kroky k vytvoření jednoduchého textového serveru a také způsob jeho ladění.

Výše popsaný server je typickým příkladem organizace moderní distribuované výpočetní techniky.

Funkce vytváření vícevrstvých aplikací

Začneme tedy vyvíjet aplikaci s třívrstvou architekturou. Chcete-li vytvořit databázový server pomocí komponent Indy, potřebujete:

Vytvořte nový projekt.
Umístěte instanci komponenty TIdTCPServer z palety Indy Servers na hlavní formulář projektu.
Nastavte vlastnost DefaultPort instance třídy TIdTCPServer1 na 6001 (doporučuje se přiřazovat velké hodnoty, abyste se vyhnuli duplikaci čísel portů v různých aplikacích) a nastavte vlastnost Active na true.
Přidejte do projektu nový modul výběrem Soubor | Nový | Data Module a umístěte na něj instance komponent SQLConnection a SQLDataSet ze záložky dbExpress na paletě komponent.
Nastavte vlastnost ConnectionName třídy SQLConnection na IBLocal a LoginPrompt na hodnotu False. Pokud jste nenakonfigurovali IBLocal v databázi zaměstnanec.gdb, dokončete nejprve tento postup.
Nastavte vlastnost SQLConnection třídy SQLDataSet na SQLConnection1 a přiřaďte vlastnost CommandText příkazu SQL: vyberte CUSTOMER, CONTACT_FIRST, CONTACT_LAST z CUSTOMER kde CUST_NO = :cust.

Ahoj všichni!

Při vývoji dalšího webového projektu vyvstal úkol - implementovat klientský software v Delphi, který by přenášel data na server metodou POST. Aplikace musí přenést text a odeslat soubory na webový server.

Implementace takového odesílání dat pomocí jazyků na straně serveru Vývoj webu(například PHP) je docela jednoduché, ale pokud potřebujete napsat aplikační software pro více uživatelů, který komunikuje se serverem, pak je to trochu složitější. Metoda přímého připojení k databázi a přes FTP k serveru od Delphi již není nutná, protože není bezpečný, není spolehlivý (změna hesel, dat připojení atd.) a vytváří další. problémy s kompatibilitou softwaru na straně klienta. Abych problém vyřešil, rozhodl jsem se napsat skripty (serverová část) v PHP, které budou zpracovávat příchozí požadavky POST a vrátit výsledek klientovi (aplikace Delphi). Výhodou tohoto přístupu je, že všechna připojení a zpracování dat probíhá na serveru, což je mnohem bezpečnější než přímé „spojení“.

Když jsem začal googlovat, spousta rozházených informací se vzdala, většinou na fórech, ale všechno to bylo na kousky. Jedna věc byla jistá, že bude použit Indy, a to komponenta IdHTTP s implementovanou metodou POST. Ve skutečnosti je vše jednoduché, tato metoda vezme dva parametry Url zdroje a DataStream (datový proud) a vrátí výsledek v textové podobě (může to být i HTML kód stránky). Hlavní bylo správné vytvoření DataStreamu (toku přenášených dat), ale postupem času se objevila další úskalí, a to ruské kódování (pokud by nebylo dobré). Tady začala zábava na několik hodin putování po internetu. Obecně dost řečí, přejděme k procvičování a implementaci softwaru.

Program je tedy jednoduchý. Musí odeslat data na server pomocí metody POST, data obsahují " Nadpis " (řádek), " Popis » ( víceřádkový text) A grafický soubor(jpg,png,gif-binární data). Server musí tato data přijmout, zpracovat, uložit grafický soubor na server a vrátit odpověď. Jako odpověď vrátíme Delphi do aplikace, stejný text pouze s přidanými popisky a odkazem na stažený soubor. Nic jiného.

Začněme implementací serverové části (podobně jako API webu). Otevřete libovolný textový editor(poznámkový blok) a napište do něj následující kód:

"; ) else ( echo "Titul: Chybí"."
"; ) //Zkontrolujte v příchozích datech přítomnost dat pole "content" if (!empty($_POST["content"]))( echo "Content: ".$_POST["content"]."
"; ) else ( echo "Obsah: chybí"."
"; ) //Zkontrolujte příchozí data na přítomnost připojeného souboru "soubor" if (!empty($_FILES["file"])) ( $finfo = pathinfo($_FILES["file"]["name" ]); / /získání informací o souboru (název, přípona atd.) //Zkontrolujte typ souboru v seznamu povolených typů (IMPROVIZACE:)) if (stripos("jpgpnggif",$finfo["přípona"] )==0)( echo ">>>>>>>Neplatný typ souboru<<<<<<<<"; exit; //Если не допустим тип, полностью останавливаем скрипт } $fname = "files/" . "testimgfile." . $finfo["extension"]; //формируем путь и новое имя файла move_uploaded_file($_FILES["file"]["tmp_name"],$fname);//сохраняем временный файл "tmp_name" в файл $fname echo "http://".$_SERVER["HTTP_HOST"]."/".$fname; //возвращаем полный путь к файлу } ?>

Poznámka! Při ukládání (přes poznámkový blok) musíte zadat kódování „UTF-8“, jinak budou problémy se zobrazením azbuky!

Scénář se snažil poskytnout podrobné komentáře. Zkopírujte tento skript na svůj webový server, pokud jej nemáte, můžete pro test použít můj skript, který se nachází na adrese: http://api..php

Rozvržení využívá tyto komponenty: Label, Button (2 ks), Edit (2 ks), Memo (2 ks), CheckBox, OpenDialog, IdHTTP. Zadejte následující názvy komponent (vlastnost „ název”):

Upravit (název) – Jméno=název;
Upravit (cesta k souboru) – Jméno = imgfile;
Poznámka (obsah) – Jméno = obsah;
Poznámka (výsledek) – Jméno = odpověď;
Knoflík(…) - Jméno = chkfile;
Tlačítko (POST) – Jméno = PostBut;
OpenDialog (dialogové okno pro výběr souboru) – Název = PictDialog;

Nechme IdHTTP1 a CheckBox1 beze změny (unavení! :)))).

Aby nedošlo náhodou" Upravit» cesta k úpravě( imgfile), nastavte jeho vlastnost ReadOnly na True. Stejně tak v imgfile A chkfile Nastavte vlastnost Enabled na hodnotu false. Aktivujeme je pomocí CheckBoxu, tzn. Poskytneme možnost vybrat si, zda nahrát obrázek nebo ne.

Pro OpenDialog( PictDialog) musíte nastavit filtr (vlastnost Filtr) takto:

Vlastní vizuální příprava je u konce! Začněme kódovat!

V projektu vygenerujeme datový tok pomocí typu zahrnutého v Indy - TidMultiPartFormDataStream. Přestože jsme narazili na možnosti implementace pomocí TStream, práce s TidMultiPartFormDataStream – jednodušší!

Abychom tento typ zpřístupnili našemu projektu, musíme do Uses přidat následující knihovnu: IdMultipartFormData.

Pro CheckBox1 vytvořte událost OnClick (poklepáním myší na objekt) a přidejte k této události následující kód:

Procedure TForm1.CheckBox1Click(Sender: TObject); begin //aktivace nebo deaktivace prvků cesty k souboru a dialogových tlačítek imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; konec;

Zde objekty aktivujeme imgfile Achkfile v závislosti na přítomnosti zaškrtnutí (pokud je zaškrtávací políčko zaškrtnuto, objekty se stanou aktivními).

Nyní uspořádáme výběr obrázků. Chcete-li to provést, vytvořte na tlačítku událost OnClick chkfile(také dvojitým kliknutím na objekt) a napište následující:

Procedure TForm1.chkfileClick(Sender: TObject); begin //otevřete dialog a zadejte úplnou cestu k souboru do imgfile(TEdit) if PictDialog.Execute then imgfile.Text:= PictDialog.FileName; konec;

Tato událost spustí dialog pro výběr obrázku a pokud uživatel klikne na „ OTEVŘENO“, pak bude přidána cesta k tomuto souboru imgfile.

A nyní se dostáváme ke konečnému tlačítku „POST“. Vytvořte událost OnClick pro toto tlačítko a přidejte následující kód:

Procedure TForm1.PostButClick(Sender: TObject); var dataPost:TIdMultiPartFormDataStream; begin dataPost:=TIdMultiPartFormDataStream.Create; dataPost.AddFormField("title",title.Text,"utf-8").ContentTransfer:= "8bit"; dataPost.AddFormField("content",content.Text,"utf-8").ContentTransfer:= "8bit"; if CheckBox1.Checked a (trim(imgfile.Text)="") then //kontrola, zda je soubor vybrán nebo ne begin ShowMessage("Musíte vybrat grafický soubor!"); výstup; konec; if CheckBox1.Checked then dataPost.AddFile("file",imgfile.Text,""); //přidejte pole se souborem response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Free; end;

Takže popořadě (i když jsou komentáře):

Datapost – objekt typu TIdMultiPartFormDataStream. Umožňuje vytvořit strukturu požadavku POST sestávající z polí různých typů.

dataPost . AddFormField (" titul ", titul . Text ," utf -8 "). Content Transfer := " 8 bit "; – přidá do DataPost pole s názvem „title“, hodnotu z „title.Text“, nastaví kódování přenášených dat na „utf-8“ (parametr je volitelný, ale bez jeho explicitního označení se azbuka přenáší s otazníky „?“) a velmi důležitou metodu „Přenos obsahu“. Bez této metody jsou data odesílána na server " abrakadabra" Vezměte prosím na vědomí, že název pole („název“) na odesílající straně se musí shodovat se jménem zadaným ve skriptu: $_POST["název"].

Data se přenášejí podobně jako pole „obsah“.

dataPost . Přidat soubor (" soubor ", imgfile . Text ,"") – tímto řádkem vytvoříme stream s daty ze souboru.

To je vše, data jsou vygenerována, zbývá je pouze přenést do skriptu na serveru a obdržet odpověď:

response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,);

protože TMemo nerozumí značce konce řádku "
", pomocí funkce " " jej nahradíme srozumitelným zalomením řádků "#13#10".

Když je vše dokončeno, vymažte paměť z objektu DataPost pomocí řádku:

datapost.Free;

I když v našem příkladu k tomu dojde automaticky na konci procedury, ale přesto...

Skutečný výsledek programu na obrazovce:

Můžeme tak na server poslat tolik dat nebo souborů, kolik chceme, zpracovat tato data na serveru a zpětně hlásit aplikaci výsledek skriptu. Může to být dokonce jen 0 nebo 1, což bude signalizovat aplikaci, aby reagovala dále.

Všechno. Hodně štěstí všem. Doufám, že informace byly užitečné a najdete pro ně využití.

Hotový příklad a skript si můžete stáhnout.

Celý kód modulu:

Jednotka PostUnit; rozhraní používá Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient IdHTTP, IdMultipartFormData, Vcl.ExtDlgs; typ TForm1 = class(TForm) IdHTTP1: TIdHTTP; název: TEdit; obsah: TMemo; PostBut: TButton; odpověď: TMemo; Label1: TLabel; Label2: TLabel; Label3: TLabel; imgfile:TEdit; chkfile: TButton; Label4: TLabel; CheckBox1: TCheckBox; PictDialog:TOpenDialog; procedure PostButClick(Sender: TObject); procedure chkfileClick(Sender: TObject); procedure CheckBox1Click(Sender: TObject); private ( Private deklarace ) public ( Public deklarace ) end; var Form1: TForm1; implementace ($R *.dfm) procedure TForm1.CheckBox1Click(Sender: TObject); begin //aktivace nebo deaktivace prvků cesty k souboru a dialogových tlačítek imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; konec; procedure TForm1.chkfileClick(Sender: TObject); begin //otevřete dialog a zadejte úplnou cestu k souboru do imgfile(TEdit) if PictDialog.Execute then imgfile.Text:= PictDialog.FileName; konec; procedure TForm1.PostButClick(Sender: TObject); var dataPost:TIdMultiPartFormDataStream; begin dataPost:=TIdMultiPartFormDataStream.Create; dataPost.AddFormField("title",title.Text,"utf-8").ContentTransfer:= "8bit"; dataPost.AddFormField("content",content.Text,"utf-8").ContentTransfer:= "8bit"; if CheckBox1.Checked a (trim(imgfile.Text)="") then //kontrola, zda je soubor vybrán nebo ne begin ShowMessage("Musíte vybrat grafický soubor!"); výstup; konec; if CheckBox1.Checked then dataPost.AddFile("file",imgfile.Text,""); //přidejte pole se souborem response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Free; end; end.

Serge Dosyukov Mike Pham

Tento článek ukazuje, jak vytvořit samostatnou webovou službu pomocí sady Indy a Delphi 7 a jak používat sadu Indy k podpoře webových služeb založených na SOAP v Delphi 7. Další informace o vytváření webových služeb naleznete ve vynikajícím článku Nicka Hodgese na webu komunity Borland: Shakespeare on the Web.

Dříve nebo později možná budete muset vytvořit server, který je samostatným HTTP serverem a podporuje webové služby. Můžete například chtít vytvořit aplikační server založený na SOAP pro vícevrstvou aplikaci vytvořenou pomocí Delphi.

Úvod

Online nápověda Delphi poskytuje vynikající pokyny krok za krokem, jak vytvořit webovou službu, server MIDAS (COM, DCOM), ale prakticky neexistují žádné informace o vytvoření samostatné n-vrstvé aplikace MIDAS založené na SOAP.

Dříve publikoval Dave Nottage. Tento článek popsal myšlenku, jak vytvořit webovou službu v Delphi 6 s podporou SOAP a schopností publikovat rozhraní SOAP Datamodulu, to znamená, že vám tento článek umožnil naučit se, jak vytvořit vlastní n-vrstvu. systémy MIDAS.

Borland Delphi 7 a nová sada Indy mají vestavěnou podporu pro tuto funkci.

Navzdory vestavěné podpoře však tato funkce není zdokumentována.

Nedávné příspěvky na síťové konferenci Borland a prohledávání webu pomocí serveru Google umožnily autorům vyvinout způsob, jak převést existující kód z Delphi 6 do Delphi 7. Ale všechno má svůj čas.

hlavní myšlenka

Tento článek je prvním dílem třídílného seriálu. Popisuje hlavní ustanovení. Druhá a třetí část budou věnovány některým problémům a způsobům jejich řešení. Začněme popisovat hlavní myšlenku.

být samostatným HTTP serverem;
použít Indy jako platformu;
podpora publikování prostřednictvím protokolu SOAP;
být schopen publikovat SOAP DataModules, což by vám umožnilo vytvořit váš vlastní n-tier server založený na SOAP/HTML.

HTTP server a SOAP

Mnoho lidí zná Indy a již dříve používalo komponenty THTTPServeru. Je snadné umístit tuto komponentu na formulář žádosti, ale jak zajistíte, aby podporovala SOAP? V adresáři "C:Program FilesBorlandDelphi7SourceIndy" naleznete soubor IdHTTPWebBrokerBridge.pas. To je přesně to, co potřebujete.

Tento soubor není součástí spustitelného souboru Indy, takže jej musíte zahrnout do svého aktuálního projektu jako standardní soubor projektu. (Ke kompilaci projektu budete také potřebovat soubor IdCompilerDefines.inc.) Tyto soubory je nutné zkopírovat do aktuálního adresáře projektu. Ke zvýšení rychlosti mohou být nutné změny kódu, proto je nejlepší uchovávat tyto soubory odděleně od distribuce Indy.

Následuje popis implementace náhradní komponenty z THTTPServeru, rozšířené o podporu paketů SOAP, nazvané TIdHTTPWebBrokerBridge. Tato konstrukce je třída, která dědí z TCustomHTTPServer a podporuje základní vazbu požadavku.

Protože tato třída není přístupná z palety, budete ji muset při provádění kódu definovat jako běžný objekt.

Tento objekt lze použít úplně stejným způsobem jako běžný THTTPServer, s výjimkou těch dalších vlastností, které umožňují provoz se SOAP.
Nejprve se však podívejme na přípravu potřebného kódu.

WebBroker a Indy

Pro ty, kteří již dříve vytvořili webové služby, víte, že je používáte WebBroker. Delphi 7, stejně jako Delphi 6, používá k podpoře SOAP architekturu WebBroker.

Proto je třeba vytvořit modul TWebModule a umístěte do něj následující tři komponenty: THTTPSoapDispatcher, THTTPSoapPascalInvoker a TWSDLHTMLPublish. Všechny jsou dostupné na záložce WebServices palety komponent. Po propojení SOAPDispatcher s SOAPPascalInvoker je formulář žádosti připraven. Konečný výsledek by měl být něco jako to, co je znázorněno na následujícím obrázku:

(modul uWebModule.pas)

Nejlepší je nechat vše tak, jak je, protože pro tento formulář není třeba měnit ani spouštět žádný vlastní kód.

WebModule a Indy

Pojďme k další části kódu potřebného k implementaci HTTP serveru.

Jak můžete vidět, TIdHTTPWebBrokerBridge má metodu RegisterWebModuleClass, která vám umožňuje zaregistrovat svůj vlastní modul WebModule a zpřístupnit jej serveru.

Po vytvoření objektu serveru fServer tedy stačí zavolat třídu fServer.RegisterWebModuleClass (TwmSOAPIndy).

Poznámka. V normální implementaci TIdHTTPWebBrokerBridge bude objekt TwmSOAPIndy vytvořen pokaždé, když je přijat požadavek. To samozřejmě není nutné. Třídu lze tedy upravit tak, aby bylo zajištěno trvalé vytvoření tohoto objektu, dokud objekt Server existuje. Další informace naleznete v dokumentaci implementace třídy.

Úvod do Indy. Vývoj aplikací klient-server pomocí Indy v Delphi

Úvod

hlavní myšlenka

HTTP server a SOAP

WebBroker a Indy

WebModule a Indy

Je server připraven?