Introduktion till Indy. Utveckla klient-serverapplikationer med Indy i Delphi

Indy-komponenter som används i Delphi 6.

Utöver grundläggande internettjänster och protokoll finns det ett brett utbud av tilläggstjänster, vars möjligheter ofta används av internetutvecklare. Dessutom är möjligheten att visa information med en webbläsare inte alltid en acceptabel lösning för internetapplikationer. I det här fallet är det rimligt att använda internetinfrastrukturen för datautbyte och tillhandahålla informationsvisning genom mer komplexa klientapplikationer utvecklade till exempel i Delphi.

Låt oss säga att du behöver implementera specialiserad serverlogik som inte ingår i vanliga webbservrar. För att lösa denna klass av problem inkluderar Delphi Internet Direct (Indy)-biblioteket från Nevrona Designs (http://www.nevrona.com/Indy/). Detta bibliotek, utvecklat specifikt för Borland Delphi, har redan åtta versioner, varav den senaste ingår i ny version Delphi. Uppsättningen av komponenter är uppdelad i tre grupper: klient (Indy Client), server (Indy Servers) och auxiliary (Indy Misc).

Indy Clients och Indy Server s

De flesta Indy Client- och Indy Servers-komponenter är par som motsvarar klient- och serverdelarna av protokollen och tjänsterna (med undantag för vissa, huvudsakligen server, komponenter som TunnelMaster och TunnelSlave), och tillåter användning av protokoll som TCP/IP , UDP, NNTP, SMTP, FTP, HTTP, samt tjänsterna ECHO, FINGER, WHOIS, etc.

Indy-klientkomponenter skrivs med sockets. Klientsidans uttag kräver en anslutning till servern. Om anslutningen upprättas kan klienten och servern börja utbyta meddelanden. Dessa meddelanden är av en annan karaktär, men vanligtvis sker utbytet med ett specifikt protokoll (till exempel HTTP)

TIdTCPClient och TIdTCPServer

Dessa komponenter används för att stödja ett av huvudnätverksprotokollen - TCP (Transmission Control Protocol), och är också basklasserna för TIdSMTP- och TIdFTP-komponenterna. Klassen TIdTCPServer har en ThreadMgr-egenskap som är noll som standard. Om ThreadMgr är noll när TIdTCPServer är aktiverad kommer klassen TIdThreadMgrDeafault att skapas implicit. Annars används den installerade processhanteraren.

TIdUDPClient och TIdUDPServer

Dessa komponenter används för att stödja nätverksprotokoll UDP (User Datagram Protocol) och är också basklasserna för ett antal andra Indy-komponenter.

TIdChargenServer

Komponenten används för att generera slumpmässiga symboler, vanligtvis för teständamål.

TIdDayTime och TIdDayTimeServer

Komponenterna används för att tillhandahålla tidsservice. Klienten begär och servern rapporterar aktuellt datum och tid.

TIdDNSResolver

Detta är en klientkomponent som betjänar förfrågningar från en DNS-server (Domain Name Service). DNS-serverfrågor är utformade för att ersätta en dators namn med dess IP-adress. TIdDNSResolver är en ättling till klassen TIdUDPClient.

TIDDICTServer

En serverkomponent som stöder Dictionary Server Protocol (DICT), en ordbok på serversidan baserad på TCP-protokollet som tillåter en klient att få åtkomst till en ordbok för naturligt språk.

TIdDISCARDServer

Serverkomponenten som stöder postservern. Inspelningarna kan användas som ett felsöknings- och mätverktyg. Registertjänsten lämnar helt enkelt över all data till den som är villig att ta emot den.

TI dEcho och TI deCHOServer

Komponenterna är utformade för att tillhandahålla en svarstjänst, som vanligtvis används för att kontrollera nätverkets tillstånd. Klienten skickar ett textmeddelande till servern, servern returnerar meddelandet till klienten. Om meddelandet är förvanskat fungerar nätverket fel.

TIdFinger och TIdFingerServer

Komponenterna är utformade för att tillhandahålla ett protokoll som tillåter en användare att fråga data angående närvaron av andra användare på systemet. Vissa servrar hanterar sådana klientförfrågningar. Genom att använda detta par av komponenter kan du betjäna klientförfrågningar som bestämmer närvaron av andra användare på systemet.

Komponenten inkluderar fullt stöd för filöverföringsprotokollet - FTP (File Transfer Protocol). Passiv och aktiv dataöverföring stöds, liksom operationer som GET och PUT, radering av kataloger, erhållande av kvoter, fil- och katalogstorlekar. TI dFTP använder klassen TIdSimpleServer för att fungera. När en FTP-filöverföring pågår öppnas en sekundär TCP-anslutning för dataöverföring och stängs när data har överförts. Denna anslutning kallas en "datalänk", unik för varje fil som överförs.

TIdGopher och TIdGopherServer

Dessa komponenter är utformade för att tillhandahålla ett nätverksprotokoll som har ersatts Nyligen från WWW (World Wide Web) HTTP-protokoll. Servern som implementerar detta protokoll tillhandahåller ett hierarkiskt distribuerat dokumentflödesstödsystem. Ett exempel på användningen av detta par av komponenter, som finns i katalogen demosindyGopherClient och demosindy GopherServer, visar hur detta protokoll kan användas för att tillhandahålla lokalt nätverk information om filer som finns på din dator, inklusive stängda.

TIdHostNameServer

En serverkomponent utformad för att skicka det lokala servernamnet till klienter.

TIdHTTP och TIdHTTPServer

Komponenterna används för att tillhandahålla HTTP-nätverksprotokollet (versionerna 1.0 och 1.1 stöds, inklusive GET-, POST- och HEAD-operationer). Dessutom tillhandahålls stöd för autentisering och användning av proxyservrar. Serverkomponenten används för att tillhandahålla tjänster till en annan webbserver som stöder ett givet protokoll. TIdHTTPServer underlättar implementeringen av funktioner som cookies, tillståndshantering etc.

TIdIcmpClient

En klientkomponent utformad för att tillhandahålla Internet Control Message Protocol (ICMP), som används för att utföra ping-operationer och nätverksspårning.

En klientkomponent utformad för att tillhandahålla Post Office Protocol (POP), inklusive stöd för MIME-kodning och avkodning, och multibyte-teckenöverföring.

TIdIMAP4Server

En serverkomponent utformad för att stödja IMAP-operationer (Internet Message Access Protocol) på servern. Protokollet låter dig söka efter meddelanden E-post på servern. Skillnaden mellan IMAP- och POP-protokollen är att POP-protokollet kräver extra minne för att lagra data, och IMAP-protokollet kommer åt servern istället för klientmaskinen. IMAP4 skapades för att ersätta POP3, men POP3 är fortfarande en allmänt använd standard till denna dag.

TIdIRCServer

En serverkomponent utformad för att stödja de vanligaste tjänsteoperationerna på Internet, vanligen kallad chatt. Komponenten ger grundläggande byggklossar för IRC-server (Internet Relay Chat).

TIdMappedPortTCP

En serverkomponent utformad för att skapa mappade portar, som ofta används i proxyservrar. Metoderna för den här komponenten låter dig mappa en port till en annan. Till exempel kan port 80 mappas till port 3000, och alla förfrågningar till den första porten (port 80) skulle vidarebefordras till den andra porten (port 3000).

TIdNNTP och TIdNNTPServer

Dessa komponenter krävs för att stödja Network News Transfer Protocol (NNTP) som används i nyhetstjänster. Klientkomponenten inkluderar stöd för MIME-kodning och avkodning, samt stöd för multibyte-tecken och alternativa kodningar. Serverkomponenten låter dig skapa nyhetsservrar. Det är viktigt att notera att TIdNNTPServer inte är en fullfjädrad nyhetsserver, utan en komponent som tillhandahåller den grundläggande funktionaliteten för en sådan server.

TIdQOTD och TIdQOTDServer

Komponenterna används för att tillhandahålla tjänsten Dagens offert. Klientkomponenten ansluter till serverkomponentinstansen för att få den dagliga offerten. Varje serverinstans innehåller en unik referensdatabas.

En klientkomponent designad för användning i SMTP-applikationer (Simple Mail Transfer Protocol) som ger stöd för autentisering, MIME-kodning och avkodning och stöd för flerbytetecken.

En klientkomponent utformad för att tillhandahålla SNTP (Simple Network Time Protocol) - en tidstjänst. Kan användas för att ansluta till valfri tidstjänst för att fastställa aktuellt datum och tid.

TIdSimpleServer

Serverkomponent som ger en lättviktig TCP-server. Låter dig organisera en punkt-till-punkt-anslutning. Den används för att skapa servrar med en enda användare, det vill säga den kan bara betjäna en anslutning åt gången. Till skillnad från TIdTCPServer-komponenten skapar den inte sekundära processer när man väntar på förfrågningar från klienter och när man bearbetar dessa förfrågningar. Med andra ord, om servern betjänar en begäran från en klient, och vid den tidpunkten en annan klient kontaktar den för att ansluta, kommer den att blockeras till slutet av behandlingen av den första begäran.

TIdTelnet och TIdTelnetServer

Klientkomponenten används för att organisera fjärrsessioner på en annan dator, inklusive konsolförhandlingar och autentisering. Kommunikationsprotokollet förutsätter närvaron av en person som interagerar interaktivt med servern. Klientkomponenten har inte bildskärmsstöd eller terminalemulering, utan tillhandahåller helt enkelt en anslutning till serverdelen. Vanligtvis används TIdTelnetServer-serverprotokollet för att organisera fjärrdatabaser med ett textgränssnitt för interaktiv interaktion med klienter.

TIdTime och TIdTimeServer

Klientkomponenten är ett alternativ till TIdSNTP-komponenten för att bestämma tid. Det är viktigt att notera att formaten för de två protokollen är olika. TIdTime är baserat på RFC 868-formatet (returnerar tiden i den interna UNIX OS-standarden, utför alla nödvändiga konverteringar). Serverkomponenten fungerar likadant som DayTime-servern. Kan användas för att implementera en tidstjänst på lokal dator. Ingen ytterligare kod krävs, skapa bara en instans av TIdTimeServer som returnerar tiden för serverdatorns interna klocka.

TIdTrivialFTP och TIdTrivialFTPServer

Dessa komponenter är nödvändiga för att organisera ett enkelt filöverföringsprotokoll. Klientkomponenten i detta protokoll används för att ansluta till en instans av motsvarande serverkomponent. Protokollet är avsett för privata, lätta, lokala fall av filöverföring, till exempel i lokala nätverk eller för att ladda (ladda upp) routingtabeller till routrar. På grund av de försvagade egenskaperna hos detta protokoll rekommenderas inte användningen av det när du använder autentiseringsalgoritmer eller andra säkerhetsmekanismer. Huvudsyftet med detta protokoll är att överföra filer till en hårdvaruenhet i syfte att modifiera den.

TIdTunnelMaster och TIdTunnelSlave

Servertunnelkomponenter används i proxyservrar för att organisera flera logiska anslutningar över en fysisk (tunnel). Dessa klasser kan användas för olika ändamål, till exempel för att organisera en hemlig anslutning över icke-hemliga kanaler.

TIdWhois och TIdWhoIsServer

Den här klientkomponenten ansluter till vilken standard Whois-server som helst, vilket gör att du kan få information om domäner. Serverkomponenten tillhandahåller de grundläggande funktionerna hos en NIC-server.

Indy Övrigt

Palettsidan Indy Diverse komponenter inkluderar BASE64, UUE, Quoted Printable och andra vanliga e-postkommunikationsformat, kodare (MD2, MD4 och MD5) för kryptografistandarder som används för att lagra lösenord och elektroniska signaturer i en oåterkallelig (svårt att tyda) form, såväl som många andra användbara komponenter och verktyg som ofta används i utvecklingen av internetapplikationer.

TIdAntiFreeze

På grund av de blockbaserade algoritmerna för Indy-komponenter verkar det ofta som att applikationen har fastnat medan anslutningen fungerar. För att eliminera användningen av sekundära processer (trådar) när du organiserar kommunikation för att förhindra att applikationen fryser, räcker det att placera den angivna komponenten på formuläret.

Komponenten fungerar genom att analysera förfrågningar från TCP/IP-protokollstacken och skicka meddelanden till applikationen under fördröjningen när externa anslutningar blockeras, vilket skapar en illusion av att köra kod. Eftersom komponenten endast påverkar blockerade anslutningar för huvudprocessen, krävs inte användning av TIdAntiFreeze i applikationens sekundära processer. Tänk på att TIDAntiFreeze-komponenten saktar ner anslutningarna eftersom huvudprocessen periodvis avbryts för att bearbeta meddelanden. Av detta följer att man måste se till att applikationen som utvecklas inte lägger för mycket tid på att bearbeta meddelanden, inklusive OnClick, OnPaint, OnResize, etc. Till viss del kan detta kontrolleras genom egenskaperna för klassen TIdAntiFreeze. Användningen av denna komponent är inte obligatorisk, men den låter dig lösa problemet med att synkronisera anslutningar med applikationens visuella gränssnitt.

TIdDateTimeStamp

En klass för att utföra matematik för datum och tid relaterad till det faktum att internetprotokoll använder olika datum- och tidsformat; dessutom kan klienter och servrar finnas i olika tidszoner.

TIdIPWatch

Det är en timerbaserad komponent som ständigt övervakar förändringar i datorns IP-adress. Komponenthändelser inträffar när en förändring upptäcks. Denna komponent används vanligtvis för att upptäcka om en dator är ansluten till Internet eller något annat nätverk. Ändringen av IP-adress i den här situationen kan uppstå på grund av att IP-adressen tilldelas av DHCP-servern (Dynamic Host Configuration Protocol) vid anslutning till det nya nätverket.

TIdLogDebug

Syftet med den här komponenten är att fånga upp händelser från vilken klient eller serverkomponent som helst och placera en registrering av händelsen i specificerad fil. Den här komponenten är mycket användbar för att felsöka Indy-komponenter.

TIdMessage

Komponenten används i kombination med andra komponenter för att korrekt dekryptera eller koda meddelanden. Dessa kan vara POP-, SMTP- och NNTP-komponenter. Klassen stöder MIME-kryptering och dekryptering, multibyte-tecken och ISO-kodning.

TIdNetwork Calculator

En av få Indy-komponenter som kan användas när man bygger applikationer. Nätverkskalkylatorn kan användas för att utföra beräkningar på IP-adresser, inklusive nätverksmasker, subnät, nätverksklasser, etc.

TIdThreadMgrDefault

Komponenten ger kontroll över sekundära processer som standard. Skapas när någon Indy-komponent som stöder processhantering inte har en instans av klassen TIdThreadManager definierad. Komponenten ger endast grundläggande funktioner för att hantera sekundära processer: skapa och förstöra dem på begäran.

TIdThreadMgrPool

En mer avancerad processhanteringskomponent än TIdThreadMgrDefault eftersom den slår samman processer snarare än att skapa eller förstöra dem på begäran.

TIdVCard

VCard är den elektroniska motsvarigheten till ett visitkort och kan innehålla ägarens personliga information och grafiska data.

TIdIMFDecoder

Designad för avkodning av Internetmeddelanden. Det är en ättling till TIdCoder-klassen, precis som alla andra kodarkomponenter. Klassen TIdCoder avkodar enligt ARPA Internet textmeddelandeformatstandard RFS-822, som föreslogs i augusti 1982, och USENET meddelandestandard RFC 1036, som föreslogs i december 1987.

Komponenten utökar TIdCoder-klassen för att tillåta detektering av RFS-822-format efter huvudkontext, vilket ger dekryptera-vid-mottagning-läge och MIME-kryptering och dekryptering. TIdIMFDecoder-komponenten används i klassen TIdMessageClient för att avkoda mottagna och sända meddelanden.

TIdQuotedPrintableEncoder

QuotedPrintableEncoder låter dig dekryptera text i det angivna formatet. Kan fungera som en fristående komponent med en specificerad kodningstyp, vilket gör att meddelanden som innehåller en ny kodningstyp kan överföras.

TIdBase64Encoder

Implementerar ytterligare en krypteringsalgoritm som gör det möjligt att överföra icke-utskrivbara tecken.

TIdUUEncoder

Implementerar en av de första krypteringsalgoritmerna, UU-kodning. Används ibland när artiklar skickas till en nyhetstjänst.

TIdXXEncoder

Det är osannolikt att denna krypteringsmetod någonsin kommer att användas. I huvudsak är detta samma UU-kodning, men med en annan krypteringstabell.

TIdCoderMD2

Komponenter med olika typer av MD (Message Digest) krypteringsalgoritm. De är alla shuffle-baserade, enkelriktade och har inga dekrypteringsalgoritmer.

Komponenter av protokollklienter och servrar kan användas för att utveckla server- och klientinternetapplikationer, tillsammans med eller istället för grundläggande (ClientSocket, ServerSocket) och andra komponenter från Internet- och Fastnet-paletten. Indy-komponenter använder inte WebBroker-arkitekturen och implementerar lågnivåstöd för Internetprotokoll och tjänster direkt i källkoden (källkoder ingår).

TIdConnectionInterceptOpenSSL och TIdServerInterceptOpenSSL

SSL-protokollet - Secure Sockets Layer, som säkerställer sekretess och tillförlitlighet för kommunikation mellan två applikationer, har två lager. På den låga nivån av ett flerskiktstransportprotokoll (som TCP) är SSL ett inspelningsprotokoll och används för att kapsla in olika protokoll på högre nivå. Fördelen med SSL är att det är ett oberoende applikationsprotokoll, men ett protokoll på högre nivå kan användas ovanpå SSL.

SSL tillhandahåller kommunikationssäkerhet, som har tre huvudfunktioner: tillhandahålla en konfidentiell anslutning; kryptering med offentlig nyckel(används för att bekräfta adressatens äkthet); stöd för tillförlitlighet i dataöverföring.

Symmetrisk kryptografi används för att kryptera data (t.ex. DES, RC4, etc.).
Digital signatur tillhandahålls med asymmetrisk kryptering med publik nyckel (till exempel RSA, DSS, etc.).
Tillförlitlighet för kommunikation, meddelandetransport inkluderar kontroll av meddelandets integritet genom MAC-korrigeringskoder, säkra hashfunktioner (t.ex. SHA, MD5, etc.) med hjälp av MAC-beräkningar.

I kombination med HTTP och serverautentisering ger SSL nödvändiga funktioner kryptering och bibehåller vidare den etablerade anslutningen, dubbelkontroll av webbserverns äkthet, etc. Det är viktigt att förstå att SSL endast skyddar kommunikation under dataöverföring och inte ersätter andra säkerhetsmekanismer.

Komponenterna TIdConnectionInterceptOpenSSL och TIdServerInterceptOpenSSL tillhandahåller anslutningar på både klientsidan och serversidan med SSL-protokollet. Det bör noteras att komponenterna TIdConnectionInterceptOpenSSL och TIdServerInterceptOpenSSL endast är tillgängliga i Delphi 6 och inte i Kylix. Detta beror på komplexiteten i protokollet, som i fallet med en Windows-implementering är baserat på operativsystemets funktioner.

Exempel på användning av Indy-komponenter finns i /Delphi6/Demos/Indy-katalogerna. Totalt innehåller Indy-biblioteket i version 8.0 69 komponenter. Det anges att i version 9.0 kommer det angivna biblioteket att innehålla 86 komponenter. Alla komponenter är enhetliga och ingår i både Delphi 6 och Kylix, vilket gör att de kan användas för att utveckla plattformsoberoende applikationer. Alla Indy-komponenter stöder multithreading.

Indy-komponenterna implementerar nästan all funktionalitet som finns i Internet- och Fastnet-komponenterna, vilket tydligt framgår av tabellen.

	Fastn et komponenter	Indy komponenter	Syfte med komponenter
1	TserverSocket, TClientSocket	TIdTCPserverSocket, TIdTCPClientSocket	Interaktion mellan två datorer (klient och server) med hjälp av TCP/IP-protokollet
2	TNMDayTime	TIdDayTime, TIdDayTimeServer	Fråga servern för aktuell tid
3	TNMEcho	TIdEcho, TIdEchoServer	Används för att kommunicera med svarsservern
4	TNMFinger	TIdFinger, TIdFingerServer	Används för att hämta information om användaren från en sökserver på Internet
5	TNMFTP	TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer	Tillhandahåll filöverföring med FTP-protokoll
6	TNMHTTP	TIdHTTP, TIdHTTPServer	Använd HTTP-protokoll för datautbyte
7	TNMMsgServ, TNMMsg		Används för att förmedla enkelt textmeddelanden från klient till server
8	TNMNNTP	TIdNNTP, TIdNNTPServer	Stöder datautbyte med nyhetsserver
9	TNMPOP3	TIdPOP3	Används för att ta emot e-post från en e-postserver som använder POP3-protokollet
10	TNMSMTP	TIdSMTP	Används för att skicka e-post via Mejl server Internet
11	TNMSrm, TNMSrmServ		Sänder binär data som skrivits till en ström med TCP/IP-protokollet
12	TNMUDP	TIdUDP, TIdUDPServer	Överför data med UDP-protokollet
13	TpowerSock, TNMGeneralServer		Komponentinkapslade klasser som är grunden för att skriva dina egna klienter (Powersock) och servrar (NMGeneralServer)
14	TNMUUPocessor	TIdUUEncoder, TIdUUDecoder	Utför omkodning binära filer till MIME- eller UUENCODE-format
15	TNMURL		Konverterar strängar till HTML-format och utför omvänd konvertering

Undantagen är klasser som TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, som antingen implementerar föråldrade protokoll eller har funktionalitet implementerad i en stor grupp av alternativa klasser.

Men till skillnad från sina föregångare - Internet- och Fastnet-komponenterna, innehåller Indy rikare serverkomponenter och komponenter för dataomkodning och kryptering, samt autentiseringsstöd (Indy Misc-palett). Som framgår av tabellen ovan tillhandahålls huvudprotokollen och tjänsterna inte bara av klienten utan också av serverkomponenter. Dessa är tidstjänster, svarstjänster, inhämtning av användarinformation, samt HTTP, NNTP, UDP-protokoll och till och med den enklaste versionen av FTP.

Några exempel på användning av Indy-komponenter

I Indy-komponenter som finns i Delphi definieras IP-adressen i Host-egenskapen, vanligtvis endast i klientapplikationer. Serverbaserade komponenter har metoder som gör att du kan starta eller stoppa polling av motsvarande port - till exempel att ändra egenskapen Active för IdTCPServer-komponenten startar eller stoppar polling av motsvarande port. När anslutningen mellan klienten och servern är upprättad kan dataöverföringen börja.

Indy-komponenter lägger stor vikt vid säkerhet och tillförlitlighet vid arbete med data. Till exempel har IdTCPClient-komponenten Connect och Disconnect metoder. Använda en programmeringsteknik som koden nedan från klientsidan:

Med TCPClient börja Connect; försök lstMain.Items.Add(ReadLn); slutligen Koppla bort; slutet; slutet;

och använda egenskapen Connection som skickas som en parameter till AThread-instansen av klassen TIdPeerThread från serversidan:

Med AThread.Connection börjar WriteLn("Hej från Basic Indy Server-server."); Koppla ifrån; slutet;

du kan räkna med antingen normal utförande av anslutningen eller korrekt felhantering.

Notera ReadLn- och WriteLn-metoderna för motsvarande klasser - de liknar standard Pascal I/O-satser. Detta är en hyllning till UNIX-programmeringstekniken, där de flesta systemoperationer utförs genom att läsa och skriva till motsvarande filer.

Precis som Fastnet-komponenter har Indy-komponentklasser händelser som kan användas för att tillhandahålla händelsehantering. Du kan till exempel ordna att ett meddelande visas på ett formulär när du ansluter till en klient:

Procedur TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Betjänar klient ]"; slutet;

Indy tillhandahåller komponenter som implementerar protokoll med klient- och serverdelar som är unika för detta bibliotek. Komponenterna TIdGopherServer och TIdGopher, tack vare metoderna GetExtendedMenu, GetFile, GetMenu, GetTextFile på klientsidan och ReturnGopherItem, SendDirectoryEntry på serversidan, hjälper till att visa filer olika typer, inklusive de som är markerade som dolda, såväl som kataloger på fjärrdator(liknande vad dir *.*-kommandot gör i operativ system MS-DOS).

Med hjälp av IdSMTP- och IdMessage-komponenterna kan du enkelt skapa din egen webbapplikation som kan skicka e-post med SMTP-protokollet.

I det här fallet är IdMessage-klassen (en av 23 komponenter från Indy Misc-sidan) ansvarig för att generera meddelandet, som följer av dess namn, och IdSMTP är för att organisera anslutningen till e-postservern.

Tekniken som används i Indy använder låsande läs- och skrivoperationer. Alla Connect-operationer som används i Indy väntar på att anslutningen ska slutföras. När du arbetar med Indy-klientkomponenter behöver du vanligtvis göra följande:

begära en anslutning till servern;
göra läs- och skrivförfrågningar till servern (beroende på typen av server utförs steget en gång eller upprepas många gånger);
avsluta anslutningen till servern och koppla från.

Indy-komponenter är designade för att ge en ultrahög abstraktionsnivå. Invecklarna och detaljerna i TCP/IP-stacken är dolda för programmeraren så att han kan fokusera på uppgiften.

Följande lilla exempel visar en typisk klientbönsession:

Med IndyClient börjar Host:= "zip.pbe.com"; // Värd att anropa Port:= 6000; // Port för att anropa servern på Connect; prova // Din kod går här äntligen Koppla bort; slutet; slutet;

I exemplet, även om anslutningen till servern inte upprättas, kommer anslutningen att avslutas på ett elegant sätt på grund av användningen av try-finally-satsen.

Indys serverkomponenter beskriver en mängd olika servermodeller som kan användas beroende på dina behov och det protokoll du använder.

TIdTCPServer är den mest använda serverkomponenten, som skapar en sekundär process oberoende av huvudapplikationsprocessen. Den skapade processen väntar på inkommande förfrågningar från potentiella klienter. En individuell sekundär process skapas för varje klient vars begäran den svarar på. Händelser som inträffar under underhållsprocessen är relaterade till sammanhanget för motsvarande processer.

Med andra ord, för varje klientanslutning använder klassen TIdTCPServer en unik sekundär tråd genom att anropa den trådens OnExecute-händelsehanterare. Den formella parametern för OnExecute-metoden är en referens till en instans av klassen Athread som motsvarar den skapade tråden. Connection-egenskapen för den här klassen är en referens till klassen TIdTCPConnection, vars instans skapas för att bearbeta klientförfrågan. TIdTCPConnection stöder läsning och skrivning över anslutningen, samt upprättande och avslutande av en kommunikationssession.

UDP-protokollet fungerar utan att först upprätta en anslutning till servern (varje skickat paket är en oberoende uppsättning data och inte en del av en större session eller anslutning). Medan TIdTCPServer skapar separata trådar för varje anslutning, använder TIdUDPServer antingen en huvudtråd eller en enda sekundär tråd som hanterar alla UDP-protokollförfrågningar. När TIdUDPServer är aktiv skapas en tråd för att lyssna efter inkommande UDP-paket. För varje paket som tas emot höjs en OnUDPRead-händelse antingen på huvudtråden eller i kontexten av lyssningstråden, beroende på värdet på egenskapen ThreadedEvent. När ThreadedEvent utvärderas till False inträffar händelsen på huvudtråden, annars inträffar den på lyssnartråden. Medan händelsen bearbetas blockeras andra serveroperationer. Därför är det viktigt att se till att OnUDPRead-procedurer körs så snabbt som möjligt.

Om du behöver skapa en ny klientapplikation för en befintlig server med hjälp av ett befintligt protokoll, är ditt jobb enbart att utveckla och felsöka klientapplikationen. Men när vi ska utveckla både klient- och serverapplikationer med ett befintligt eller nytt protokoll står vi inför det klassiska "kyckling och ägg"-problemet. Var ska man börja programmera - från klienten eller från servern?

Självklart måste både klienten och servern skapas så småningom. För många applikationer, särskilt de som använder ett textbaserat protokoll (som HTTP), är det lättare att börja bygga applikationen genom att designa servern. Och för felsökning finns det en bekväm klient som redan finns. Detta är en Telnet-konsolapplikation som är tillgänglig på både Windows och UNIX.

Om du skriver konsolen telnet kommando 127.0.0.1 80 med IP-adressen för den lokala datorn och portnummer 80, som används som standard av webbservrar, då kommer applikationen att svara med texten som visas i Fig. 6, för Windows 2000 OS och IIS 5.0.

För att skapa den enklaste servern med Indy-komponenter behöver du:

Om du behöver designa en server som inte bara korrekt informerar sina klienter när anslutningen bryts, utan också ger dem information om felsituationer som har inträffat, använd try-except-satsen istället för try-finally - till exempel som visas i följande exempel:

Procedur TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: Sträng; börja med AThread.Connection försök försök s:= ReadLn; // Utför serverns uppgift här // om inget undantag görs, // skriv ut serverns svar WriteLn(s); förutom på e: Exception do begin WriteLn(e.Message); end; //on end; //försök utom att slutligen Koppla bort; slut; slut;

Detta lilla exempel visar stegen för att skapa en enkel textserver, samt hur man felsöker den.

Servern som beskrivs ovan är ett typiskt exempel på organisationen av modern distribuerad datoranvändning.

Funktioner för att skapa flerskiktsapplikationer

På senare tid har flera servrar använts alltmer för att tillfredsställa klientförfrågningar. En server av denna typ, som har mottagit en klientförfrågan och delvis förberett den för vidare bearbetning, kontaktar en annan server och skickar den eller de transformerade förfrågningarna till den. Den andra klassens server kan i sin tur kommunicera med andra servrar. Således kan vi prata om en serverarkitektur med flera nivåer.

Därefter kommer vi att skapa en dataåtkomstserver vars syfte är att returnera data från databasen. Den här servern läser eller skriver inte direkt till databasfilerna. Istället kommunicerar den med databasservern på jakt efter den data som klienten kräver.

Så vi börjar utveckla en applikation med en arkitektur i tre nivåer. För att skapa en databasserver med Indy-komponenter behöver du:

Skapa ett nytt projekt.
Placera på huvudform projektinstans av TIdTCPServer-komponenten från paletten Indy Servers.
Ställ in DefaultPort-egenskapen för klassinstansen TIdTCPServer1 till 6001 (det rekommenderas att tilldela stora värden för att undvika duplicering av portnummer över olika applikationer), och ställ in egenskapen Active till true.
Lägg till en ny modul till projektet genom att välja Arkiv | Nytt | Data Module, och placera instanser av SQLConnection- och SQLDataSet-komponenterna på den från fliken dbExpress på komponentpaletten.
Ställ in egenskapen ConnectionName för klassen SQLConnection till IBLocal och LoginPrompt till False. Om du inte har konfigurerat IBLocal på databasen werknemer.gdb, slutför denna procedur först.

Introduktion till Indy

Introduktion till Indy
Upplagt av Chad Z. Hower
Hemsida: http://www.atozedsoftware.com
Översättning: Anatoly Podgoretsky
introduktion
Jag skrev den här artikeln när aktuell version var Indy 8.0. Mycket av den här artikeln är tillämplig och mycket användbar i framtida versioner av Indy. Om du gillade den här artikeln och vill läsa mer djupgående artiklar, kolla in boken Indy in Depth.
Indy körs i blockeringsläge
Indy använder blockerande uttag. Blockeringsläge liknar fil läs-skriv. Vid läsning eller skrivning av data återställer funktionen inte kontroll förrän operationen är klar. Skillnaden mot att arbeta med filer är att samtalet kan ta längre tid, eftersom de begärda uppgifterna inte finns ännu, detta beror på hastigheten som ditt nätverk eller modem fungerar med.
Till exempel anropas en metod helt enkelt och väntar tills kontroll återgår till larmpunkten. Om samtalet lyckades kommer kontrollen att returneras från metoden, om ett fel uppstår kommer ett undantag att göras.
Lockdown är inte dödlig
På grund av blockeringsläget har vi blivit slagen många gånger av våra motståndare, men blockeringsläget är inte djävulen.
Problemet uppstod efter portering av Winsock till Windows. I Unix löstes problemet vanligtvis genom gaffel (liknande multi-threading, men med separata processer istället för trådar). Unix-klienter och demoner var tvungna att dela processerna som skulle köras och använda blockeringsläge. Windows 3.x kunde inte parallelliseras och stödde inte mycket trådning. Användning av ett blockerande gränssnitt frös användargränssnittet och gjorde att program inte svarade. Därför lades icke-blockerande lägen till i WinSock, vilket gjorde att Windows 3.x med dess begränsningar kunde använda Winsock utan att blockera programmets huvud- och enda tråd. Detta krävde annan programmering, och Microsoft och andra förtalade passionerat blockeringslägen för att dölja bristerna i Windows 3.x.
Sedan kom Win32, som kunde stödja multi-threading. Men vid det här laget var deras hjärnor redan röriga (det vill säga utvecklarna ansåg att blockering av uttag var djävulens skapelse), och det var redan svårt att ändra vad de hade gjort. Därför fortsätter smutskastningen av blockerande regimer.
I verkligheten har Unix bara blockerande uttag. Blockerande uttag har också sina fördelar och är mycket bättre för multi-threading, säkerhet och andra aspekter. Vissa tillägg har lagts till i Unix för icke-blockerande uttag. De fungerar dock väldigt annorlunda än på Windows. De är också icke-standardiserade och inte särskilt vanliga. Blockerande uttag i Unix används i nästan alla fall, och kommer att fortsätta att användas.
Fördelar med blockeringsläge·Lättare att programmera - Blockeringslägen är lättare att programmera. All användarkod kan finnas på ett ställe och exekveras i en naturlig, sekventiell ordning. ·Lättare att porta till Unix - Eftersom Unix använder blockerande uttag är portabel kod lättare att skriva i det här fallet. Indy använder detta faktum för att skriva enhetlig kod. ·Det är bekvämare att arbeta med trådar - Eftersom blockerande uttag har en sekvens förvärvad av ärftlighet, så de är mycket lätta att använda i trådar.
Nackdelar med blockeringsläge · Användargränssnittet fryser i klienter - Ett blockerande socketanrop ger inte tillbaka kontroll förrän det har slutfört sin uppgift. När ett sådant anrop görs på applikationens huvudtråd kan applikationen inte behandla användarmeddelanden. Detta gör att användargränssnittet fryser, att fönster inte uppdateras och inga andra meddelanden bearbetas förrän kontrollen återställs från den blockerande uttaget.
TIDAntiFreeze-komponent
Indy har en speciell komponent som löser frysproblemet användargränssnitt. Lägg bara till en TIDAntiFreeze-komponent var som helst i din applikation och du kan ringa blockerande samtal utan att frysa användargränssnittet.
TIDAntiFreeze körs på en intern timer utanför samtalsstacken och anropar Application.ProcessMessages när timeouten går ut. Externa anrop till Indy fortsätter att blockera och fungerar därför precis som utan att använda TIdAntiFreeze-komponenten. Genom att använda TIdAntiFreeze kan du få alla fördelar med att blockera uttag, utan några av nackdelarna.
Kodtrådar (trådning)
Med blockerande uttag används kodströmmar nästan alltid. Icke-blockerande uttag kan också använda gängor, men detta kräver en del ytterligare bearbetning och deras fördelar i detta fall går förlorade jämfört med blockerande uttag.
Fördelar med trådar·Ställa in prioriteringar - Prioriteringarna för enskilda trådar kan konfigureras. Detta gör att enskilda uppgifter kan allokeras mer eller mindre CPU-tid. ·Inkapsling - Varje anslutning kan innehålla något sken av ett gränssnitt med en annan anslutning. ·Säkerhet - Varje tråd kan ha olika säkerhetsattribut. ·Flera processorer - ger en fördel på system med flera processorer. · Inget behov av serialisering - ger full samtidighet. Utan mycket trådning måste alla förfrågningar behandlas i en tråd. Därför måste varje uppgift delas upp i små bitar så att den kan fungera snabbt. Medan ett block körs tvingas alla andra vänta på att det ska slutföra. I slutet av ett block exekveras nästa och så vidare. Med multithreading kan varje uppgift programmeras som en enda enhet och operativsystemet fördelar tid mellan alla uppgifter.
Omröstningstrådar
Att skapa och förstöra trådar är mycket resurskrävande. Detta är en särskilt svår uppgift för servrar som har kortlivade anslutningar. Varje server skapar en tråd, använder den under en kort tid och förstör den sedan. Detta resulterar i att trådar skapas och tas bort mycket ofta. Ett exempel på detta är en webbserver. En enda begäran skickas och ett enkelt svar returneras. När du använder en webbläsare kan hundratals anslutningar och avbrott inträffa när du tittar på vilken webbplats som helst.
Omröstningstrådar kan korrigera denna situation. Istället för att skapa och förstöra trådar på begäran, väljs trådar från en lista med oanvända men redan skapade trådar från poolen. När en tråd inte längre behövs återförs den till poolen istället för att förstöras. Trådar i poolen är markerade som oanvända och förbrukar därför inte CPU-tid. För ännu större förbättringar kan trådar dynamiskt anpassa sig till systemets nuvarande behov.
Indy stöder trådundersökning. Trådpoolen i Indy är tillgänglig via TIdThreadMgrPool-komponenten.
Många trådar
En tungt laddad server kan kräva hundratals eller till och med tusentals trådar. Det finns en vanlig uppfattning att hundratals och tusentals trådar kan döda ditt system. Detta är en falsk tro.
På de flesta servrar väntar trådar på data. Medan du väntar på ett blockerande samtal är tråden inaktiv. I en server med 500 trådar kan endast 50 vara aktiva samtidigt.
Antalet trådar som körs på ditt system kan överraska dig. Med ett minsta antal körande servrar och de angivna kör applikationer mitt system har skapat 333 trådar, även med 333 trådar är CPU:n bara 1% laddad. Tungt lastad IIS-server(Microsoft Internet Information Server) kan skapa hundratals och tusentals trådar.
Trådar och globala avsnitt
Med flera trådar måste du säkerställa dataintegritet när du kommer åt den. Detta kan vara svårt för programmerare som inte har arbetat med trådar. Men i allmänhet behöver de flesta servrar inte använda global data. De flesta servrar utför isolerade funktioner. Varje tråd utför sin egen isolerade uppgift. Globala läs/skrivsektioner är en funktion i många flertrådade applikationer, men är inte typiska för servrar.
Metodik Indy
Indy skiljer sig från andra Winsock-komponenter du är van vid. Om du har arbetat med andra komponenter, då den bästa lösningen kommer att glömma hur de fungerar. Många andra komponenter använder icke-blockerande (asynkrona) samtal och fungerar asynkront. De måste reagera på händelser, skapa en tillståndsmaskin och köra frekventa vänteloopar.
Till exempel, med andra komponenter, när du anropar en anslutning måste du antingen vänta på att anslutningshändelsen inträffar eller vänta i en slinga på att en egenskap indikerar att anslutningen har inträffat. Med Indy kan du anropa Connect-metoden och vänta tills den kommer tillbaka. En återbetalning kommer att utfärdas om anslutningen lyckas eller om ett undantag görs om det finns ett problem. Att arbeta med Indy är därför mycket likt att arbeta med filer. Indy låter dig lägga all din kod på ett ställe, istället för att sprida den över olika händelser. Dessutom är Indy väldigt enkelt och bekvämast när man arbetar med trådar.
Hur annorlunda är Indy?
Kort översikt · Blockerande samtal används · Ej händelseorienterade - det finns händelser, men de används för informationsbehov och är egentligen inte nödvändiga. · Designad för trådar - Indy är designad för trådar, men kan användas utan trådar. Sekventiell programmering
Detaljerad recension
Indy använder inte bara blockerande samtal (synkront) utan fungerar också så här. En typisk Indy-session ser ut så här:
med IndyClient börjar
Ansluta; Prova
// Gör dina saker här
slutligen Koppla bort; slutet;
slutet;
Med andra komponenter ser det ut så här:
procedur TFormMain.TestOnClick(Avsändare: TComponent);
Börja
med SocketComponent börjar
Ansluta; Prova
medan den inte är ansluten börjar
om IsError börja då
Avbryta;
slutet;

OutData:= "Data att skicka";
medan length(OutData) > 0 börjar
Application.ProcessMessages;
slutet;
slutligen Koppla bort; slutet;
slutet;
slutet;
procedur TFormMain.OnConnectError;
Börja
IsError:= Sant;
slutet;
procedur TFormMain.OnRead;
var
i: heltal;
Börja
i:= SocketComponent.Send(OutData);
OutData:= Copy(OutData, i + 1, MaxInt);
slutet;
Många komponenter gör inte ett särskilt bra jobb med att isolera programmeraren från stacken. Många komponenter, istället för att isolera användaren från stackens komplexitet, lämnar helt enkelt användaren åt det eller tillhandahåller ett omslag över stapeln.
Indy speciellt sätt
Indy är designad från grunden för att vara flertrådig. Att bygga servrar och klienter i Indy liknar att bygga servrar och klienter i Unix. Unix-applikationer anropar vanligtvis stacken direkt med lite eller inget abstraktionslager.
Vanligtvis har Unix-servrar en eller flera lyssningsprocesser som övervakar inkommande klientförfrågningar. För varje kund som behöver betjänas, a ny process. Detta gör programmeringen enkel, varje process för endast en klient. Varje process körs i sitt eget säkerhetssammanhang, som ställs in av lyssningsprocessen eller processen baserat på befintliga rättigheter, identitet eller andra saker.
Indy-servrar fungerar ungefär på samma sätt. Windows, till skillnad från Unix, kan inte multiplicera processer bra, men det fungerar bra med trådar. Indy-servrar skapar en separat tråd för varje klientanslutning.
Indy-servrar tilldelar en lyssningstråd som är skild från programmets huvudkodtråd. Lyssningstråden lyssnar efter inkommande förfrågningar från klienter. För varje klient som den svarar på skapas en ny tråd för att betjäna klienten. Relevanta händelser servas sedan i sitt sammanhang av denna ström.
Indy kundrecension
Indy är designad för att ge en mycket hög abstraktionsnivå. TCP/IP-stackens krånglighet och detaljer är dolda för programmeraren. Vanligtvis ser en typisk klientsession i Indy ut så här:
med IndyClient börjar
Host:= "zip.pbe.com"; // Värd att ringa
Port:= 6000; // Port att anropa servern på
Ansluta; Prova
// Gör dina saker här
slutligen Koppla bort; slutet;
slutet;
Indy serveröversikt
Indy-serverkomponenter skapar en lyssningstråd som är isolerad från huvudprogrammets kodtråd. Lyssningstråden lyssnar efter inkommande förfrågningar från klienter. För varje klient som den svarar på skapas en ny tråd för att betjäna klienten. Motsvarande händelser servas sedan i sammanhanget för den tråden.

Praktiska exempel
Följande exempel bör hjälpa dig att komma igång med komponenter för lätt att använda, men för att visa exempel gjorda som enkla applikationer. Vissa projekt är gjorda för att visa olika situationer. Dessa exempel är också tillgängliga för nedladdning som zip-filer.
Anmärkning från översättaren: länken på webbplatsen fungerar inte.
Exempel 1 - Postnummerverifiering
Det första projektet är gjort så enkelt som möjligt. Sök efter postnummer, klienten frågar servern vilken stad och delstat det angivna postnumret tillhör.
För de som bor utanför USA och inte vet vad ett postnummer är, är det ett postnummer som anger leveransplatsen. Postnummer består av 5 siffror.
Protokoll
Det första steget i att bygga en server och klient är att utveckla ett protokoll. För standardprotokoll definieras detta av motsvarande RFC. För postnummer definieras protokollet nedan.
De flesta kommunikationsprotokoll fungerar i textläge. Exchange innebär att ett kommando sänds och som svar status och eventuellt data. Protokollen är inte begränsade till utbyte utan vanlig text används fortfarande. Även protokollet för att fastställa postnummer är textbaserat. Oformaterad text gör protokoll lätta att felsöka och låter olika programmeringsspråk och operativsystem kommunicera.
Efter anslutning skickar servern ett hejmeddelande och accepterar sedan kommandot. Detta kommando kan vara "Postnummer x" (där x är postnumret) eller "Avsluta". Som svar på ZipCode-kommandot skickas ett svar i form av en enda rad med svaret eller tom rad om koden inte hittas. Kommandot Quit får servern att stänga anslutningen. Servern kan acceptera flera kommandon innan kommandot Quit skickas.
Serverns källkod

enhet ServerMain;

gränssnitt

använder

typ

TformMain = klass(TForm)

IdTCPServer1: TIdTCPServer;

procedure FormCreate(Sender: TObject );

procedure FormDestroy(Avsändare: TObject ) ;

procedure IdTCPServer1Connect(AThread: TIdPeerThread) ;

privat

ZipCodeList: TStrings;

offentlig

slutet ;

FormMain: TformMain;

genomförande

(R*.DFM)

procedur TformMain.IdTCPServer1Connect (AThread: TIdPeerThread) ;

Börja

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

slutet ;

SCommand: sträng ;

Börja

SCommand:= ReadLn ;

slutet ;

procedure TformMain.FormCreate (Avsändare: TObject );

Börja

ZipCodeList:= TStringList.Create ;

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

slutet ;

procedur TformMain.FormDestroy (Avsändare: TObject );

Börja

ZipCodeList.Free ;

slutet ;

slutet.

De enda Indy-specifika delarna i projektet är IdTCPServer1-komponenten, IdTCPServer1Connect och IdTCPServer1Execute-metoderna.
Formuläret innehåller IdTCPServer1-komponenten av typen TIdTCPServer. Följande egenskaper har ändrats: ·Active = True - När programmet startar lyssnar servern. ·DefaultPort = 6000 - Portvärde för detta projekt. Servern lyssnar efter klientförfrågningar på denna port.
Metoden IdTCPServer1Execute är associerad med serverns OnExecute-händelse. OnExecute-händelsen uppstår efter att klientanslutningen har accepterats. OnExecute-händelsen skiljer sig från andra händelser du känner till. OnExecute körs i kontexten av en tråd. Trådhändelsen höjs och ges AThread-argumentet som skickas till metoden. Detta är viktigt eftersom flera OnExecute-händelser kan köras samtidigt. Detta görs för att servern ska kunna fungera utan att skapa en ny komponent. Det finns även metoder som kan åsidosättas vid konstruktion av arvingar.
OnConnect-händelsen aktiveras efter att anslutningen har accepterats och en tråd har skapats för den. I denna server detta används för att skicka ett välkomstmeddelande till klienten. Om så önskas kan detta även göras i OnExecute-händelsen.
OnExecute-händelsen kan avfyras flera gånger tills anslutningen kopplas bort eller förloras. Detta eliminerar behovet av att kontrollera anslutningen för frånkoppling eller förlust i en slinga inom en händelse.
IdTCPServer1Execute använder två grundläggande funktioner, ReadLn och WriteLn. ReadLn läser en sträng från anslutningen och WriteLn skickar en sträng till anslutningen.
sCommand:= ReadLn;
Ovanstående kod tar en sträng från klienten och placerar den i den lokala sCommand-strängvariabeln.

om SameText (sCommand, "QUIT" ) börja sedan

slut annars om SameText (Kopiera (sCommand, 1 , 8 ), "Postkod " ) och börja sedan

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

slutet ;

Därefter kontrolleras sCommand för giltiga kommandon.
Om kommandot är "Avsluta" utförs frånkoppling. Ingen läsning eller skrivning är tillåten efter frånkoppling. Efter att händelsen avslutats anropar den inte längre avlyssningstråden, utan rensar tråden och avslutar anslutningen.
Om kommandot är "ZipCode", så extraheras parametern efter kommandot och tabellen skannas för närvaron av staden och staten. Staden och staten skickas sedan till klienten, eller så skickas en tom sträng om det inte finns någon matchning.
Därefter avslutas metoden. Servern kommer att återuppta händelsen igen så snart ett nytt kommando kommer, vilket gör att klienten kan skicka flera kommandon.
Klientens källkod

enhet ClientMain;

gränssnitt

använder

Windows, meddelanden, SysUtils, klasser, grafik, kontroller, formulär, dialogrutor,

StdCtrls, ExtCtrls, IdAntiFreezeBase,

IdAntiFreeze, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient;

typ

TformMain = klass(TForm)

Klient: TIDTCPClient;

IdAntiFreeze1: TIdAntiFreeze;

Panel1: TPanel;

Panel2: TPanel;

MemoInput: TMemo;

LboxResults: TListBox;

Panel3: TPanel;

Knapp1: TBnapp;

Knapp2: TBnapp;

Etikett1: TLabel;

procedure Button2Click(Sender: TObject );

procedure Button1Click(Sender: TObject );

privat

offentlig

slutet ;

FormMain: TformMain;

genomförande

(R*.DFM)

procedure TformMain.Button2Click (Avsändare: TObject );

Börja

MemoInput.Clear ;

LboxResults.Clear ;

slutet ;

procedure TformMain.Button1Click (Avsändare: TObject );

I: heltal ;

S: sträng ;

Börja

ButnLookup.Enabled := true ; Prova

LboxResults.Clear ;

med klienten börjar

Ansluta; Prova

LboxResults.Items.Add(ReadLn);

för i:= 0 till memoInput.Lines .Count - 1 börjar

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

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

S:= ReadLn ;

om s = "" börja då

S:= "-- Ingen post hittades för detta postnummer.";

slutet ;

LboxResults.Items.Add(s);

LboxResults.Items.Add("");

slutet ;

WriteLn("Avsluta");

slutligen Koppla bort; slutet ;

slutet ;

slutligen butnLookup.Enabled := true ; slutet ;

slutet ;

slutet.

De enda delarna som är specifika för klientkomponenten är Button1Click-metoden.
Klientkomponenten är av typen TIdTCPClient och placeras på formuläret. Följande egenskaper har ändrats: ·Host = 127.0.0.1 - Servern finns på samma maskin som klienten. ·Port = 6000 - Serverport
Button1Click-metoden är associerad med OnClick-händelsen för Button1-komponenten. När knappen klickas anropas denna metod. Indy-delen av denna metod kan reduceras till följande: 1.Anslut till servern (Anslut;) 1.Läs hälsningen från servern. 1. För varje rad som användaren anger i TMemo: 1. Skicka en begäran till servern (WriteLn("Postkod " + memoInput.Lines[i]);) 1. Läsa ett svar från servern (s:= ReadLn; ) 1. Skickar kommandot Quit (WriteLn("Avsluta");) 1.Koppla bort (Koppla bort;)
Testning
Det här exemplet har testats och fungerar med TCP/IP installerat. Du kan ändra den så att den fungerar över ett nätverk från en dator till en annan. Genom att starta servern på en annan dator och ändra namn eller IP på servern på klienten.
För att testa projekt, kompilera och kör servern. Kompilera och kör sedan klienten. Ange ditt postnummer i memofältet och tryck på uppslagstangenten.
Felsökning
Textprotokoll är mycket lätta att felsöka eftersom de kan testas med Telnet. För att göra detta räcker det att känna till serverporten. ZIP Code Lookup Server lyssnar på port 6000.
Starta ZIP Code Lookup Server igen. Öppna sedan en konsol (t.ex. ett Dos-fönster). Ange nu:
telnet 127.0.0.1 6000
Du är nu ansluten till servern. Vissa servrar skickar också ett välkomstmeddelande. Vissa gör det inte. Du kommer inte att se raderna du anger. De flesta servrar ekar inte för att spara trafik. Du kan dock ändra telnet-inställningarna genom att ställa in alternativet "Echo On". Detta görs olika i olika telnet-klienter, och vissa har inte den här funktionen alls. Ange nu:
postnummer 37642
Du kommer att se serverns svar:
CHURCH HILL, TN
För att koppla från servern anger du:
sluta
Exempel 2 - databasåtkomst
Det här exemplet emulerar en server som måste utföra andra blockeringsuppgifter än socket-anrop. Många servrar tvingas arbeta under sådana förhållanden. Servrar som behöver komma åt databasen, anropa externa procedurer eller beräkningar kan ofta inte avbryta dessa samtal, eftersom de är externa samtal eller på grund av komplexiteten i detta. Åtkomst till databasen kan inte delas upp i små bitar och utvecklaren måste vänta på slutet av operationen med databasen. Detta är en funktion inte bara för databasanrop, utan också för andra operationer såsom komprimering, beräkningar och annan bearbetning av samma slag.
För demonstrationsändamål, låt oss föreställa oss att servern gör ett databasanrop som tar 5 sekunder att slutföra. För att förenkla, låt oss göra detta helt enkelt med en paus, använd Sleep(5000)-funktionen för detta, istället för att faktiskt ringa.
Det här exemplet kräver också mindre detaljer än det föregående exemplet eftersom många av begreppen ännu inte är förstått.
Källa

huvudenhet;

gränssnitt

använder

Windows, meddelanden, SysUtils, klasser, grafik, kontroller, formulär, dialogrutor,

IdBaseComponent, IdComponent, IdTCPServer;

typ

TformMain = klass(TForm)

IdTCPServer1: TIdTCPServer;

procedure IdTCPServer1Execute(AThread: TIdPeerThread) ;

privat

offentlig

slutet ;

FormMain: TformMain;

genomförande

(R*.DFM)

procedure TformMain.IdTCPServer1Execute (AThread: TIdPeerThread) ;

I: heltal ;

Börja

med AThread.Connection börjar

WriteLn("Hej. DB-server redo." );

I:= StrToIntDef(ReadLn, 0);

// Sleep ersätter ett långt DB eller annat samtal

Sömn(5000);

WriteLn(IntToStr(i * 7));

slutet ;

slutet.

Eftersom Execute-händelsen inträffar i kontexten av en tråd, kan bearbetningskoden vara av valfri längd. Varje klient har sin egen tråd och blockerar inte andra klienter.
Testning
För att testa DB-servern, kompilera och kör den. Anslut till den med Telnet till port 6001. Servern kommer att svara med ett välkomstmeddelande. Skriv in nummer. Servern kommer att "behandla" din förfrågan och svara inom 5 sekunder.

Indy-komponenter som används i Delphi 6.

Låt oss säga att du behöver implementera specialiserad serverlogik som inte ingår i vanliga webbservrar. För att lösa denna klass av problem inkluderar Delphi Internet Direct (Indy)-biblioteket från Nevrona Designs (http://www.nevrona.com/Indy/). Detta bibliotek, utvecklat specifikt för Borland Delphi, har redan åtta versioner, varav den senaste ingår i den nya versionen av Delphi. Uppsättningen av komponenter är uppdelad i tre grupper: klient (Indy Client), server (Indy Servers) och auxiliary (Indy Misc).

Indy-klienter och Indy-servrar

TIdTCPClient och TIdTCPServer

TIdUDPClient och TIdUDPServer

Dessa komponenter används för att stödja nätverksprotokollet UDP (User Datagram Protocol) och är också basklasserna för ett antal andra Indy-komponenter.

TIdChargenServer

Komponenten används för att generera slumpmässiga symboler, vanligtvis för teständamål.

TIdDayTime och TIdDayTimeServer

Komponenterna används för att tillhandahålla tidsservice. Klienten begär och servern rapporterar aktuellt datum och tid.

TIdDNSResolver

TIDDICTServer

En serverkomponent som stöder Dictionary Server Protocol (DICT), en ordbok på serversidan baserad på TCP-protokollet som tillåter en klient att få åtkomst till en ordbok för naturligt språk.

TIdDISCARDServer

TI dEcho och TI deCHOServer

TIdFinger och TIdFingerServer

TIdFTP

TIdGopher och TIdGopherServer

Dessa komponenter är utformade för att tillhandahålla ett nätverksprotokoll som nyligen har ersatts från WWW (World Wide Web) av HTTP-protokollet. Servern som implementerar detta protokoll tillhandahåller ett hierarkiskt distribuerat dokumentflödesstödsystem. Ett exempel på användning av detta par av komponenter, som finns i katalogerna \demos\indy\GopherClient och \demos\indy\GopherServer, visar hur du med detta protokoll kan tillhandahålla information på det lokala nätverket om filer som finns på din dator, inklusive stängda. .

TIdHostNameServer

En serverkomponent utformad för att skicka det lokala servernamnet till klienter.

TIdHTTP och TIdHTTPServer

TIdIcmpClient

En klientkomponent utformad för att tillhandahålla Internet Control Message Protocol (ICMP), som används för att utföra ping-operationer och nätverksspårning.

TIdPOP3

En klientkomponent utformad för att tillhandahålla Post Office Protocol (POP), inklusive stöd för MIME-kodning och avkodning, och multibyte-teckenöverföring.

TIdIMAP4Server

En serverkomponent utformad för att stödja IMAP-operationer (Internet Message Access Protocol) på servern. Protokollet låter dig söka efter e-postmeddelanden på servern. Skillnaden mellan IMAP- och POP-protokollen är att POP-protokollet kräver ytterligare minne för att lagra data, och IMAP-protokollet får åtkomst till servern istället för klientmaskinen. IMAP4 skapades för att ersätta POP3, men POP3 är fortfarande en allmänt använd standard till denna dag.

TIdIRCServer

En serverkomponent utformad för att stödja de vanligaste tjänsteoperationerna på Internet, vanligen kallad chatt. Komponenten tillhandahåller de grundläggande byggstenarna för en IRC-server (Internet Relay Chat).

TIdMappedPortTCP

TIdNNTP och TIdNNTPServer

TIdQOTD och TIdQOTDServer

TIdSMTP

En klientkomponent designad för användning i SMTP-applikationer (Simple Mail Transfer Protocol) som ger stöd för autentisering, MIME-kodning och avkodning och stöd för flerbytetecken.

TIdSNTP

TIdSimpleServer

TIdTelnet och TIdTelnetServer

TIdTime och TIdTimeServer

Klientkomponenten är ett alternativ till TIdSNTP-komponenten för att bestämma tid. Det är viktigt att notera att formaten för de två protokollen är olika. TIdTime är baserat på RFC 868-formatet (returnerar tiden i den interna UNIX OS-standarden, utför alla nödvändiga konverteringar). Serverkomponenten fungerar likadant som DayTime-servern. Kan användas för att implementera en tidstjänst på den lokala datorn. Ingen ytterligare kod krävs, skapa bara en instans av TIdTimeServer som returnerar tiden för serverdatorns interna klocka.

TIdTrivialFTP och TIdTrivialFTPServer

TIdTunnelMaster och TIdTunnelSlave

TIdWhois och TIdWhoIsServer

Indy Övrigt

Sidan Indy Diverse komponenter inkluderar BASE64, UUE, Quoted Printable och andra vanliga e-postkommunikationsformat, kodare (MD2, MD4 och MD5) för kryptografistandarder som används för att lagra lösenord och elektroniska signaturer i en irreversibel (svår att dekryptera) form, samt många andra användbara komponenter och verktyg som ofta används i utvecklingen av internetapplikationer.

TIdAntiFreeze

TIdDateTimeStamp

TIdIPWatch

TIdLogDebug

Syftet med den här komponenten är att fånga upp händelser för alla klient- eller serverkomponenter och placera en registrering av händelsen i den angivna filen. Den här komponenten är mycket användbar för att felsöka Indy-komponenter.

TIdMessage

TIdNetwork Calculator

TIdThreadMgrDefault

TIdThreadMgrPool

En mer avancerad processhanteringskomponent än TIdThreadMgrDefault eftersom den slår samman processer snarare än att skapa eller förstöra dem på begäran.

TIdVCard

VCard är den elektroniska motsvarigheten till ett visitkort och kan innehålla ägarens personliga information och grafiska data.

TIdIMFDecoder

TIdQuotedPrintableEncoder

TIdBase64Encoder

Implementerar ytterligare en krypteringsalgoritm som gör det möjligt att överföra icke-utskrivbara tecken.

TIdUUEncoder

Implementerar en av de första krypteringsalgoritmerna, UU-kodning. Används ibland när artiklar skickas till en nyhetstjänst.

TIdXXEncoder

Det är osannolikt att denna krypteringsmetod någonsin kommer att användas. I huvudsak är detta samma UU-kodning, men med en annan krypteringstabell.

TIdCoderMD2

Komponenter med olika typer av MD (Message Digest) krypteringsalgoritm. De är alla shuffle-baserade, enkelriktade och har inga dekrypteringsalgoritmer.

TIdConnectionInterceptOpenSSL och TIdServerInterceptOpenSSL

SSL tillhandahåller kommunikationssäkerhet, som har tre huvudfunktioner: tillhandahålla en konfidentiell anslutning; offentlig nyckelkryptering (används för att bekräfta mottagarens identitet); stöd för tillförlitlighet i dataöverföring.

Symmetrisk kryptografi används för att kryptera data (t.ex. DES, RC4, etc.).
Den digitala signaturen tillhandahålls med hjälp av asymmetrisk kryptering med publik nyckel (till exempel RSA, DSS, etc.).
Tillförlitlighet för kommunikation, meddelandetransport inkluderar kontroll av meddelandets integritet genom MAC-korrigeringskoder, säkra hashfunktioner (t.ex. SHA, MD5, etc.) med hjälp av MAC-beräkningar.

I kombination med HTTP och serverautentisering tillhandahåller SSL nödvändiga krypteringsfunktioner och upprätthåller vidare den etablerade anslutningen genom att korskontrollera webbserverns identitet etc. Det är viktigt att förstå att SSL endast skyddar kommunikation under dataöverföring och inte ersätter andra säkerhetsmekanismer.

Indy-komponenterna implementerar nästan all funktionalitet som finns i Internet- och Fastnet-komponenterna, vilket tydligt framgår av tabellen.

	Fastn et komponenter	Indy komponenter	Syfte med komponenter
1	TserverSocket, TClientSocket	TIdTCPserverSocket, TIdTCPClientSocket	Interaktion mellan två datorer (klient och server) med hjälp av TCP/IP-protokollet
2	TNMDayTime	TIdDayTime, TIdDayTimeServer	Fråga servern för aktuell tid
3	TNMEcho	TIdEcho, TIdEchoServer	Används för att kommunicera med svarsservern
4	TNMFinger	TIdFinger, TIdFingerServer	Används för att hämta information om användaren från en sökserver på Internet
5	TNMFTP	TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer	Tillhandahåll filöverföring med FTP-protokoll
6	TNMHTTP	TIdHTTP, TIdHTTPServer	Använd HTTP-protokoll för datautbyte
7	TNMMsgServ, TNMMsg		Används för att överföra enkla textmeddelanden från klient till server
8	TNMNNTP	TIdNNTP, TIdNNTPServer	Stöder datautbyte med nyhetsserver
9	TNMPOP3	TIdPOP3	Används för att ta emot e-post från en e-postserver som använder POP3-protokollet
10	TNMSMTP	TIdSMTP	Används för att skicka e-post via Internet-e-postserver
11	TNMSrm, TNMSrmServ		Sänder binär data som skrivits till en ström med TCP/IP-protokollet
12	TNMUDP	TIdUDP, TIdUDPServer	Överför data med UDP-protokollet
13	TpowerSock, TNMGeneralServer		Komponentinkapslade klasser som är grunden för att skriva dina egna klienter (Powersock) och servrar (NMGeneralServer)
14	TNMUUPocessor	TIdUUEncoder, TIdUUDecoder	Konverterar binära filer till MIME- eller UUENCODE-format
15	TNMURL		Konverterar strängar till HTML-format och utför omvänd konvertering

Några exempel på användning av Indy-komponenter

med TCPClient, börja Connect; försök lstMain.Items.Add(ReadLn); slutligen Koppla bort; slutet; slutet;

och använda egenskapen Connection som skickas som en parameter till AThread-instansen av klassen TIdPeerThread från serversidan:

med AThread.Connection börjar WriteLn("Hej från Basic Indy Server-server."); Koppla ifrån; slutet;

du kan räkna med antingen normal utförande av anslutningen eller korrekt felhantering.

procedur TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Betjänar klient ]"; slutet;

Indy tillhandahåller komponenter som implementerar protokoll med klient- och serverdelar som är unika för detta bibliotek. Komponenterna TIdGopherServer och TIdGopher, tack vare metoderna GetExtendedMenu, GetFile, GetMenu, GetTextFile på klientsidan och ReturnGopherItem, SendDirectoryEntry på serversidan, hjälper till att visa filer av olika typer, inklusive de som är markerade som dolda, såväl som kataloger på en fjärrdator (liknande som dir *.*-kommandot gör i MS-DOS-operativsystemet).

Med hjälp av IdSMTP- och IdMessage-komponenterna kan du enkelt skapa din egen webbapplikation som kan skicka e-post med SMTP-protokollet.

begära en anslutning till servern;
göra läs- och skrivförfrågningar till servern (beroende på typen av server utförs steget en gång eller upprepas många gånger);
avsluta anslutningen till servern och koppla från.

Indy-komponenter är designade för att ge en ultrahög abstraktionsnivå. Invecklarna och detaljerna i TCP/IP-stacken är dolda för programmeraren så att han kan fokusera på uppgiften.

Följande lilla exempel visar en typisk klientbönsession:

med IndyClient börjar Host:= "zip.pbe.com"; // Värd att anropa Port:= 6000; // Port för att anropa servern på Connect; prova // Din kod går här äntligen Koppla bort; slutet; slutet;

I exemplet, även om anslutningen till servern inte upprättas, kommer anslutningen att avslutas på ett elegant sätt på grund av användningen av try-finally-satsen.

Indys serverkomponenter beskriver en mängd olika servermodeller som kan användas beroende på dina behov och det protokoll du använder.

TIdTCPServer är den mest använda serverkomponenten, som skapar en sekundär process oberoende av huvudapplikationsprocessen. Den skapade processen väntar på inkommande förfrågningar från potentiella kunder. En individuell sekundär process skapas för varje klient vars begäran den svarar på. Händelser som inträffar under underhållsprocessen är relaterade till sammanhanget för motsvarande processer.

Om du behöver skapa en ny klientapplikation för en befintlig server med hjälp av ett befintligt protokoll, är ditt jobb enbart att utveckla och felsöka klientapplikationen. Men när vi måste utveckla både klient- och serverapplikationer med hjälp av ett befintligt eller nytt protokoll, står vi inför det klassiska "kyckling och ägg"-problemet. Var ska man börja programmera - från klienten eller från servern?

Om du skriver in konsolkommandot telnet 127.0.0.1 80 med IP-adressen för den lokala datorn och portnummer 80, som används som standard av webbservrar, kommer applikationen att svara med texten som visas i Fig. 6, för Windows 2000 OS och IIS 5.0.

För att skapa den enklaste servern med Indy-komponenter behöver du:

procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: Sträng; börja med AThread.Connection försök försök s:= ReadLn; // Utför serverns uppgift här // om inget undantag görs, // skriv ut serverns svar WriteLn(s); förutom på e: Exception do begin WriteLn(e.Message); end; //on end; //försök utom att slutligen Koppla bort; slut; slut;

Detta lilla exempel visar stegen för att skapa en enkel textserver, samt hur man felsöker den.

Servern som beskrivs ovan är ett typiskt exempel på organisationen av modern distribuerad datoranvändning.

Funktioner för att skapa flerskiktsapplikationer

Så vi börjar utveckla en applikation med en arkitektur i tre nivåer. För att skapa en databasserver med Indy-komponenter behöver du:

Skapa ett nytt projekt.
Placera en instans av TIdTCPServer-komponenten från paletten Indy Servers i projektets huvudform.
Ställ in DefaultPort-egenskapen för klassinstansen TIdTCPServer1 till 6001 (det rekommenderas att tilldela stora värden för att undvika duplicering av portnummer över olika applikationer), och ställ in egenskapen Active till true.
Lägg till en ny modul till projektet genom att välja Arkiv | Nytt | Data Module, och placera instanser av SQLConnection- och SQLDataSet-komponenterna på den från fliken dbExpress på komponentpaletten.
Ställ in egenskapen ConnectionName för klassen SQLConnection till IBLocal och LoginPrompt till False. Om du inte har konfigurerat IBLocal på databasen werknemer.gdb, slutför denna procedur först.
Ställ in SQLConnection-egenskapen för SQLDataSet-klassen till SQLConnection1 och tilldela CommandText-egenskapen till SQL-satsen: välj CUSTOMER, CONTACT_FIRST, CONTACT_LAST från CUSTOMER där CUST_NO = :cust.

Hej alla!

Vid utvecklingen av nästa webbprojekt uppstod uppgiften - att implementera klientprogramvara i Delphi, som skulle överföra data till servern med POST-metoden. Applikationen måste överföra text och ladda upp filer till webbservern.

Implementering av sådan datasändning med hjälp av språk på serversidan webbutveckling(till exempel PHP) är ganska enkelt, men om du behöver skriva applikationsbaserad, fleranvändarprogramvara som interagerar med servern, så är det lite mer komplicerat. Metoden att direkt ansluta till databasen och via FTP till servern från Delphi är inte längre nödvändig eftersom det är inte säkert, inte tillförlitligt (byta lösenord, anslutningsdata, etc.) och skapar ytterligare. ppå klientsidan. För att lösa problemet bestämde jag mig för att skriva skript (serverdel) i PHP som kommer att behandla inkommande POST-förfrågningar och returnera resultatet till klienten (Delphi-applikationen). Fördelarna med detta tillvägagångssätt är att alla anslutningar och databehandling sker på servern, vilket är mycket säkrare än en direkt "anslutning".

När jag började googla lämnades mycket spridd information upp, mest på forum, men allt var i bitar. En sak var säker att Indy skulle användas, nämligen IdHTTP-komponenten med POST-metoden implementerad. Faktum är att allt är enkelt, den här metoden tar två parametrar Url för en resurs och DataStream (dataström), och returnerar resultatet i textform (det kan också vara sidans HTML-kod). Huvudsaken var den korrekta bildningen av DataStream (ström av överförda data), men under vägen uppstod ytterligare fallgropar, nämligen den ryska kodningen (om den inte vore bra). Det var här det roliga började för flera timmars vandrande runt på Internet. I allmänhet, tillräckligt med prat, låt oss gå vidare till övning och implementering av programvaran.

Så programmet är enkelt. Hon måste skicka data till servern med POST-metoden, data innehåller " Rubrik " (rad), " Beskrivning » ( flerradstext) Och grafisk fil(jpg,png,gif-binära data). Servern måste acceptera denna data, bearbeta den, spara grafikfilen på servern och returnera ett svar. Som ett svar kommer vi att returnera Delphi till applikationen, samma text endast med tillagda etiketter och en länk till den nedladdade filen. Inget annat.

Låt oss börja med implementeringen av serverdelen (liknande webbplatsens API). Öppna någon textredigerare(anteckningsblock) och skriv följande kod i den:

"; ) else ( eko "Titel: Saknas"."
"; ) //Kontrollera inkommande data för närvaron av "innehålls"-fältdata if (!empty($_POST["content"]))( echo "Content: ".$_POST["content"]."
"; ) else ( eko "Innehåll: Saknas"."
"; ) //Kontrollera inkommande data för närvaron av en bifogad fil "fil" om (!empty($_FILES["fil"])) ( $finfo = pathinfo($_FILES["file"]["name" ]); / /få information om filen (namn, filtillägg, etc.) //Kontrollera filtypen i listan över tillåtna typer (IMPROVISATION:)) if (stripos("jpgpnggif",$finfo["extension"] )==0)( echo ">>>>>>>Ogiltig filtyp<<<<<<<<"; exit; //Если не допустим тип, полностью останавливаем скрипт } $fname = "files/" . "testimgfile." . $finfo["extension"]; //формируем путь и новое имя файла move_uploaded_file($_FILES["file"]["tmp_name"],$fname);//сохраняем временный файл "tmp_name" в файл $fname echo "http://".$_SERVER["HTTP_HOST"]."/".$fname; //возвращаем полный путь к файлу } ?>

notera! När du sparar (via anteckningar) måste du ange kodningen "UTF-8", annars kommer det att bli problem med att visa det kyrilliska alfabetet!

Manuset försökte ge detaljerade kommentarer. Kopiera detta skript till din webbserver, om du inte har ett kan du använda mitt skript för testet, det finns på: http://api..php

Layouten använder följande komponenter: Label, Button (2 st.), Edit (2 st.), Memo (2 st.), CheckBox, OpenDialog, IdHTTP. Ge följande komponenter namn (egenskap " namn”):

Redigera (titel) – Namn=titel;
Redigera (sökväg till fil) – Namn = imgfile;
Memo (innehåll) – Namn = innehåll;
Memo(resultat) – Namn = svar;
Knapp(…) - Namn = chkfile;
Knapp (POST) – Namn = PostBut;
OpenDialog (filvalsdialog) – Namn = PictDialog;

Låt oss lämna IdHTTP1 och CheckBox1 oförändrade (trött! :)))).

För att inte av misstag" redigera» sökväg till Edit( imgfile), ställ in dess ReadOnly-egenskap till True. Likaså kl imgfile Och chkfile Ställ in egenskapen Enabled till false. Vi kommer att aktivera dem med hjälp av CheckBox, dvs. Vi ger dig möjligheten att välja om du vill ladda upp en bild eller inte.

För OpenDialog( PictDialog) måste du ställa in filtret (Filter-egenskap) enligt följande:

Själva visuella förberedelserna är över! Låt oss börja koda!

I projektet kommer vi att generera ett dataflöde med den typ som ingår i Indy - TidMultiPartFormDataStream.Även om vi stötte på implementeringsalternativ med TStream, arbetade med TidMultiPartFormDataStream – lättare!

För att göra denna typ tillgänglig för vårt projekt måste vi lägga till följande bibliotek till Användningar: IdMultipartFormData.

För CheckBox1, skapa en OnClick-händelse (genom att dubbelklicka med musen på objektet) och lägg till följande kod till denna händelse:

Procedur TForm1.CheckBox1Click(Avsändare: TObject); börja //aktivera eller inaktiva filsökvägselementen och dialogknapparna imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; slutet;

Här aktiverar vi objekten imgfile Ochchkfile beroende på närvaron av en bock (om kryssrutan är markerad blir objekten aktiva).

Låt oss nu organisera bildvalet. För att göra detta, skapa en OnClick-händelse på knappen chkfile(även genom att dubbelklicka på objektet) och skriv följande:

Procedur TForm1.chkfileClick(Avsändare: TObject); börja //öppna dialogrutan och ange hela sökvägen till filen i imgfile(TEdit) om PictDialog.Execute sedan imgfile.Text:= PictDialog.FileName; slutet;

Den här händelsen utlöser en dialogruta för bildval och om användaren klickar på " Öppen", kommer sökvägen till den här filen att läggas till imgfile.

Och nu kommer vi till den sista "POST"-knappen. Skapa en OnClick-händelse för den här knappen och lägg till följande kod:

Procedur TForm1.PostButClick(Avsändare: 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"; om CheckBox1.Checked och (trim(imgfile.Text)="") sedan //kontrollerar om filen är vald eller inte börjar ShowMessage("Du måste välja en grafisk fil!"); utgång; slutet; if CheckBox1.Checked then dataPost.AddFile("file",imgfile.Text,""); //lägg till ett fält med filen response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Free; end;

Så, i ordning (även om det finns kommentarer):

Datapost – objekt av typ TIdMultiPartFormDataStream. Låter dig skapa en POST-förfrågningsstruktur som består av fält av olika typer.

dataPost . AddFormField (" titel ", titel . Text ," utf -8 "). ContentTransfer := " 8 bit "; – lägger till ett fält med namnet "title" i DataPost, ett värde från "title.Text", ställer in kodningen av den överförda datan till "utf-8" (parametern är valfri, men utan dess explicita indikation, kyrillisk sänds med frågetecken "?") och en mycket viktig metod "Content Transfer". Utan denna metod skickas data till servern " abrakadabra" Observera att fältnamnet ("titel") på sändningssidan måste matcha namnet som anges i skriptet: $_POST["titel"].

Data överförs på samma sätt som fältet "innehåll".

dataPost . Lägg till fil (" fil ", imgfile . Text ,"") – med den här raden skapar vi en ström med data från filen.

Det är allt, data genereras, allt som återstår är att överföra det till skriptet på servern och få ett svar:

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

därför att TMemo förstår inte radbrytningstaggen "
", kommer vi att använda " "-funktionen för att ersätta den med begripliga radbrytningar "#13#10".

När allt är klart, rensa minnet från DataPost-objektet med raden:

datapost.Gratis;

Även om detta i vårt exempel kommer att ske automatiskt i slutet av proceduren, men ändå...

Det faktiska resultatet av programmet på skärmen:

Således kan vi skicka så mycket data eller filer till servern som vi vill, bearbeta dessa data på servern och rapportera tillbaka till applikationen resultatet av skriptet. Det kan till och med bara vara 0 eller 1, vilket signalerar att applikationen ska reagera ytterligare.

Allt. Lycka till allihopa. Jag hoppas att informationen var användbar och att du kommer att kunna använda den.

Du kan ladda ner det färdiga exemplet och skriptet.

Fullständig modulkod:

Unit PostUnit; gränssnittet använder Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, IdBaseComponent, IdComponent, IdTCPConnection, Id IdHTTP, IdMultipartFormData, Vcl.ExtDlgs; typ TForm1 = klass(TForm) IdHTTP1: TIdHTTP; titel: TEdit; innehåll: TMemo; PostBut: TButton; svar: TMemo; Etikett1: TLabel; Etikett2: TLabel; Etikett3: TLabel; imgfile:TEdit; chkfile: TButton; Etikett4: TLabel; CheckBox1: TCheckBox; PictDialog:TOpenDialog; procedur PostButClick(Avsändare: TObject); procedure chkfileClick(Avsändare: TObject); procedure CheckBox1Click(Avsändare: TObject); privata ( Privata deklarationer ) offentliga ( Offentliga deklarationer ) slut; var Form1: TForm1; implementering ($R *.dfm) procedur TForm1.CheckBox1Click(Avsändare: TObject); börja //aktivera eller inaktiva filsökvägselementen och dialogknapparna imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; slutet; procedure TForm1.chkfileClick(Avsändare: TObject); börja //öppna dialogrutan och ange hela sökvägen till filen i imgfile(TEdit) om PictDialog.Execute sedan imgfile.Text:= PictDialog.FileName; slutet; procedur TForm1.PostButClick(Avsändare: 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"; om CheckBox1.Checked och (trim(imgfile.Text)="") sedan //kontrollerar om filen är vald eller inte börjar ShowMessage("Du måste välja en grafisk fil!"); utgång; slutet; if CheckBox1.Checked then dataPost.AddFile("file",imgfile.Text,""); //lägg till ett fält med filen response.Text:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Free; end; end.

Serge Dosyukov Mike Pham

Den här artikeln visar hur du skapar en fristående webbtjänst med Indy-kitet och Delphi 7, och hur du använder Indy-kitet för att stödja Delphi 7 SOAP-baserade webbtjänster. För mer information om att skapa webbtjänster, se Nick Hodges utmärkta artikel på Borland community: Shakespeare on the Web.

Förr eller senare kan du behöva skapa en server som är en fristående HTTP-server och som stöder webbtjänster. Till exempel kanske du vill skapa en SOAP-baserad applikationsserver för en n-tier applikation byggd med Delphi.

Introduktion

Delphis onlinehjälp ger utmärkta steg-för-steg-instruktioner om hur man skapar en webbtjänst, en MIDAS-server (COM, DCOM), men det finns praktiskt taget ingen information om hur man skapar en fristående n-tier SOAP-baserad MIDAS-applikation.

Tidigare publicerad av Dave Nottage. Den här artikeln beskrev idén om hur man skapar en webbtjänst i Delphi 6 med SOAP-stöd och möjligheten att publicera SOAP-gränssnitt för Datamodulen, det vill säga den här artikeln tillät dig att lära dig hur du skapar din egen n-tier MIDAS-system.

Borlands Delphi 7 och det nya Indy kitet har inbyggt stöd för denna funktionalitet.

Men trots inbyggt stöd är denna funktion inte dokumenterad.

De senaste inläggen på Borland nätverkskonferens och sökning på webben med hjälp av en Google-server har gjort det möjligt för författarna att utveckla ett sätt att konvertera befintlig kod från Delphi 6 till Delphi 7. Men allt har sin tid.

huvudtanken

Den här artikeln är den första delen av en serie i tre delar. Den beskriver de viktigaste bestämmelserna. Den andra och tredje delen kommer att ägnas åt några problem och sätt att lösa dem. Låt oss börja beskriva huvudidén.

vara en fristående HTTP-server;
använd Indy som plattform;
stödja publicering via SOAP-protokoll;
kunna publicera SOAP DataModules, vilket gör att du kan skapa din egen n-tier server baserad på SOAP/HTML.

HTTP-server och SOAP

Många känner till Indy och har använt THTTPServer-komponenter tidigare. Det är lätt att lägga in den här komponenten på en ansökningsblankett, men hur får man den att stödja SOAP? I katalogen "C:Program FilesBorlandDelphi7SourceIndy" kan du hitta filen IdHTTPWebBrokerBridge.pas. Det här är precis vad du behöver.

Den här filen är inte en del av Indys körbara fil, så du måste inkludera den i ditt nuvarande projekt som en standardprojektfil. (För att kompilera projektet behöver du också filen IdCompilerDefines.inc.) Dessa filer måste kopieras till den aktuella projektkatalogen. Kodändringar kan behövas för att öka hastigheten, så det är bäst att hålla dessa filer åtskilda från Indy-distributionen.

Följande beskriver implementeringen av en ersättningskomponent från THTTPServer, utökad för att stödja SOAP-paket, kallad TIdHTTPWebBrokerBridge. Den här konstruktionen är en klass som ärver från TCustomHTTPServer och stöder grundläggande begäranbindning.

Eftersom denna klass inte är tillgänglig från paletten, måste du definiera den som ett vanligt objekt när du kör din kod.

Detta objekt kan användas på exakt samma sätt som en vanlig THTTPServer, med undantag för de ytterligare egenskaper som möjliggör drift med SOAP.
Men låt oss först titta på att förbereda den nödvändiga koden.

WebBroker och Indy

För dig som har skapat webbtjänster tidigare vet du att du använder WebBroker. Delphi 7, liksom Delphi 6, använder WebBroker-arkitekturen för att stödja SOAP.

Därför måste du skapa en modul TWebModule och placera följande tre komponenter i den: THTTPSoapDispatcher, THTTPSoapPascalInvoker och TWSDLHTMLPublish. Alla är tillgängliga från fliken WebServices i komponentpaletten. Efter att ha länkat SOAPDispatcher med SOAPPascalInvoker är ansökningsformuläret klart. Slutresultatet bör vara ungefär som det som visas i följande figur:

(modul uWebModule.pas)

Det är bäst att lämna allt som det är, eftersom det inte finns något behov av att ändra eller köra någon anpassad kod för detta formulär.

WebModule och Indy

Låt oss gå vidare till den andra delen av koden som behövs för att implementera HTTP-servern.

Som du kan se har TIdHTTPWebBrokerBridge en RegisterWebModuleClass-metod, som låter dig registrera din egen WebModule och göra den tillgänglig för servern.

Efter att ha skapat fServer-serverobjektet behöver du alltså bara anropa klassen fServer.RegisterWebModuleClass (TwmSOAPIndy).

Notera. I en normal implementering av TIdHTTPWebBrokerBridge kommer ett TwmSOAPIndy-objekt att skapas varje gång en begäran tas emot. Uppenbarligen är detta inte nödvändigt. Därför kan klassen modifieras för att säkerställa att det här objektet skapas permanent så länge som serverobjektet finns. Det rekommenderas att du hänvisar till dokumentationen för klassimplementering för mer information.

Introduktion till Indy. Utveckla klient-serverapplikationer med Indy i Delphi

Introduktion

huvudtanken

HTTP-server och SOAP

WebBroker och Indy

WebModule och Indy

Är servern klar?