I et nøtteskall er Indy komponenter for praktisk arbeid med populære Internett-protokoller. Prinsippet for deres drift er basert på bruk av stikkontakter i blokkeringsmodus. Indy er interessant og praktisk fordi den er ganske abstrahert. Og programmering i Indy kommer ned til lineær programmering. Forresten, en oversatt artikkel er vidt distribuert på Internett, der det er ordene "blokkeringsmodusen er ikke djevelen" :)) En gang var jeg veldig underholdt av denne oversettelsen. Artikkelen er en del av boken "Depths of Indy" av Hoover og Hariri. I prinsippet trenger du ikke å lese alt for å jobbe med Indy, men jeg anbefaler likevel å gjøre deg kjent med prinsippene for hvordan Internett-protokoller fungerer. Når det gjelder det "djevelske" regimet. Et blokkerende socket-anrop returnerer faktisk ikke kontroll før det har fullført oppgaven. Når det foretas anrop på hovedtråden, kan applikasjonsgrensesnittet fryse. For å unngå denne ubehagelige situasjonen opprettet indiske utviklere TIdAntiFreeze-komponenten. Du trenger bare å kaste det på skjemaet - og brukergrensesnittet vil enkelt tegnes på nytt mens blokkerende samtaler foretas.

Du har sikkert allerede blitt kjent med innholdet i de forskjellige "Indy (...)"-fanene i Delphi. Det er mange komponenter der, og hver av dem kan være nyttige. Selv har jeg ikke jobbet med alle, fordi jeg ikke ser behovet for å studere dem uten en spesifikk oppgave.

Den grunnleggende Delphi-distribusjonen inkluderer Indy v.9 med pennies. Det vil sannsynligvis være tilrådelig å umiddelbart oppgradere til mer ny verson(Jeg har for eksempel for øyeblikket 10.0.76, men det er også senere, ser det ut til).

Det finnes klient- og serverkomponenter for å arbeide med de samme protokollene. Indy forenkler virkelig applikasjonsutvikling, i motsetning til muligheten for å utvikle samme funksjonalitet på sockets. For å opprette en forbindelse med serveren, bør du for eksempel bare kalle opp Connect-metoden. En vellykket forbindelsesetablering vil bli markert ved at metoden returnerer uten å forårsake et unntak. Hvis tilkoblingen ikke er opprettet, vil et unntak bli kastet.

"Akademisk" eksempel (koden fungerer ikke, ikke kjør den :)):

Med IndyClient gjør
begynne
Host:= "test.com";
Port:= 2000;
Koble;
Prøve
// jobbe med data (lese, skrive...)
endelig
Koble fra;
slutt;
slutt;

Vert og port kan settes i objektinspektøren eller i kjøretid.

Hvorfor kan du bruke Indy-komponenter til å analysere oppgaver? Ulike bruksområder! Det enkleste er å få sideinnholdet (alle har sikkert allerede støtt på dette) ved å bruke IdHTTP-komponenten:

Var
rcvrdata: TMemoryStream;
idHttp1: TidHttp;
begynne
idHttp1:= TidHttp.Create(nil);
rcvrdata:= TMemoryStream.Create;
idHttp1.Request.UserAgent:= "Mozilla/4.0 (kompatibel; MSIE 5.5; Windows 98)";
idHttp1.Request.AcceptLanguage:= "ru";
idHttp1.Response.KeepAlive:= sant;
idHttp1.HandleRedirects:= true;
prøve
idHttp1.Get(Edit1.Text, rcvrdata);
endelig
idHttp1.Free;
slutt;
hvis rcvrdata.Size > 0 så begynn
ShowMessage("Mottatt " + inttostr(rcvrdata.Size));
rcvrdata.SaveToFile("c:\111.tmp");
slutt;
rcvrdata.Gratis;
slutt;

Som du kan se, kan du ikke bare få innholdet på siden, men også simulere nedlasting av et dokument fra en bestemt klient. Indy-komponenter er generelt nyttige for å generere overskrifter og POST-forespørsler. Mer om dette med eksempler neste gang.

For å holde deg oppdatert med bloggoppdateringer kan du

Indy-komponenter brukt i Delphi 6.

I tillegg til grunnleggende Internett-tjenester og protokoller, er det et bredt spekter av tilleggstjenester, som ofte brukes av Internett-utviklere. I tillegg er muligheten til å vise informasjon ved hjelp av en nettleser ikke alltid en akseptabel løsning for Internett-applikasjoner. I dette tilfellet er det rimelig å bruke Internett-infrastrukturen for datautveksling, og gi informasjonsvisning gjennom mer komplekse klientapplikasjoner utviklet for eksempel i Delphi.

La oss si at du må implementere spesialisert serverlogikk som ikke er inkludert i standard webservere. For å løse denne klassen av problemer inkluderer Delphi Internet Direct (Indy)-biblioteket fra Nevrona Designs (http://www.nevrona.com/Indy/). Dette biblioteket, utviklet spesielt for Borland Delphi, har allerede åtte versjoner, hvorav den siste er inkludert i den nye versjonen av Delphi. Settet med komponenter er delt inn i tre grupper: klient (Indy Client), server (Indy Servers) og auxiliary (Indy Misc).

Indy-klienter og Indy-servere

De fleste Indy Client- og Indy Servers-komponenter er par som tilsvarer klient- og serverdelene av protokollene og tjenestene (med unntak av visse, hovedsakelig server, komponenter som TunnelMaster og TunnelSlave), og tillater bruk av protokoller som TCP/IP , UDP, NNTP, SMTP, FTP, HTTP, samt tjenester ECHO, FINGER, WHOIS, etc.

Indy-klientkomponenter er skrevet ved hjelp av sockets. Klientsidekontakten krever en tilkobling til serveren. Hvis tilkoblingen er opprettet, kan klienten og serveren begynne å utveksle meldinger. Disse meldingene er av en annen karakter, men vanligvis skjer utvekslingen ved hjelp av en bestemt protokoll (for eksempel HTTP)

TIdTCPClient og TIdTCPServer

Disse komponentene brukes til å støtte en av hovednettverksprotokollene - TCP (Transmission Control Protocol), og er også basisklassene for TIdSMTP- og TIdFTP-komponentene. TIdTCPServer-klassen har en ThreadMgr-egenskap som som standard er null. Hvis ThreadMgr er null når TIdTCPServer er aktivert, vil TIdThreadMgrDeafault-klassen bli opprettet implisitt. Ellers brukes den installerte prosessbehandleren.

TIdUDPClient og TIdUDPServer

Disse komponentene brukes til å støtte nettverksprotokoll UDP (User Datagram Protocol) og er også basisklassene for en rekke andre Indy-komponenter.

TIdChargenServer

Komponenten brukes til å generere tilfeldige symboler, vanligvis for testformål.

TIdDayTime og TIdDayTimeServer

Komponentene brukes til å gi tidsservice. Klienten ber om, og serveren rapporterer gjeldende dato og klokkeslett.

TIdDNSResolver

Dette er en klientkomponent som betjener forespørsler fra en DNS-server (Domain Name Service). DNS-serverspørringer er laget for å erstatte en datamaskins navn med IP-adressen. TIdDNSResolver er en etterkommer av TIdUDPClient-klassen.

TIDDICTServer

En serverkomponent som støtter Dictionary Server Protocol (DICT), en serversideordbok basert på TCP-protokollen som lar en klient få tilgang til en naturlig språkordbok.

TIDDISCARDServer

Serverkomponenten som støtter postserveren. Opptakene kan brukes som et feilsøkings- og måleverktøy. Journaltjenesten overlater ganske enkelt alle data til den som er villig til å motta den.

TI dEcho og TI deCHOServer

Komponentene er designet for å gi en responstjeneste, vanligvis brukt til å sjekke helsen til nettverket. Klienten sender en tekstmelding til serveren, serveren returnerer meldingen til klienten. Hvis meldingen er forvansket, fungerer nettverket feil.

TIdFinger og TIdFingerServer

Komponentene er designet for å gi en protokoll som lar en bruker spørre etter data angående tilstedeværelsen av andre brukere på systemet. Noen servere håndterer slike klientforespørsler. Ved å bruke dette komponentparet kan du betjene klientforespørsler som bestemmer tilstedeværelsen av andre brukere på systemet.

TIdFTP

Komponenten inkluderer full støtte for filoverføringsprotokollen - FTP (File Transfer Protocol). Passiv og aktiv dataoverføring støttes, samt operasjoner som GET og PUT, sletting av kataloger, innhenting av kvoter, fil- og katalogstørrelser. TI dFTP bruker TIdSimpleServer-klassen for å operere. Når en FTP-filoverføring pågår, åpnes en sekundær TCP-tilkobling for dataoverføring og lukkes når dataene er overført. Denne tilkoblingen kalles en "datalink", som er unik for hver fil som overføres.

TIdGopher og TIdGopherServer

Disse komponentene er designet for å gi en nettverksprotokoll som har blitt erstattet I det siste fra WWW (verden Wide Web) HTTP-protokoll. Serveren som implementerer denne protokollen gir et hierarkisk distribuert dokumentflytstøttesystem. Et eksempel på dette komponentparet, som ligger i katalogene \demos\indy\GopherClient og \demos\indy\GopherServer, viser hvordan denne protokollen kan brukes til å gi lokalt nettverk informasjon om filer på datamaskinen din, inkludert lukkede.

TIdHostNameServer

En serverkomponent designet for å sende det lokale servernavnet til klienter.

TIdHTTP og TIdHTTPServer

Komponentene brukes til å gi HTTP-nettverksprotokollen (versjon 1.0 og 1.1 støttes, inkludert GET-, POST- og HEAD-operasjoner). I tillegg gis det støtte for autentisering og bruk av proxy-servere. Serverkomponenten brukes til å levere tjenester til en annen webserver som støtter en gitt protokoll. TIdHTTPServer forenkler implementeringen av funksjoner som informasjonskapsler, tilstandsadministrasjon, etc.

TIdIcmpClient

En klientkomponent designet for å gi Internet Control Message Protocol (ICMP), som brukes til å utføre ping-operasjoner og nettverkssporing.

TIdPOP3

En klientkomponent designet for å gi Post Office Protocol (POP), inkludert støtte for MIME-koding og dekoding, og multibyte-tegnoverføring.

TIdIMAP4Server

En serverkomponent designet for å støtte IMAP-operasjoner (Internet Message Access Protocol) på serveren. Protokollen lar deg søke etter meldinger E-post på server. Forskjellen mellom IMAP- og POP-protokollene er at POP-protokollen krever ekstra minne for å lagre data, og IMAP-protokollen får tilgang til serveren i stedet for klientmaskinen. IMAP4 ble opprettet for å erstatte POP3, men POP3 er fortsatt en mye brukt standard den dag i dag.

TIdIRCServer

En serverkomponent designet for å støtte de mest brukte tjenesteoperasjonene på Internett, ofte kalt chat. Komponenten gir grunnleggende byggeklosser for IRC (Internet Relay Chat) server.

TIdMappedPortTCP

En serverkomponent designet for å lage kartlagte porter, som ofte brukes i proxy-servere. Metodene til denne komponenten lar deg kartlegge en port til en annen. For eksempel kan port 80 tilordnes port 3000, og alle forespørsler til den første porten (port 80) vil bli videresendt til den andre porten (port 3000).

TIdNNTP og TIdNNTPServer

Disse komponentene er nødvendige for å støtte Network News Transfer Protocol (NNTP) som brukes i nyhetstjenester. Klientkomponenten inkluderer støtte for MIME-koding og -dekoding, samt støtte for multibyte-tegn og alternative kodinger. Serverkomponenten lar deg lage nyhetsservere. Det er viktig å merke seg at TIdNNTPServer ikke er en fullverdig nyhetsserver, men en komponent som gir den grunnleggende funksjonaliteten for en slik server.

TIdQOTD og TIdQOTDServer

Komponentene brukes til å tilby tjenesten Dagens tilbud. Klientkomponenten kobles til serverkomponentforekomsten for å få det daglige tilbudet. Hver serverforekomst inneholder en unik sitasjonsdatabase.

TIdSMTP

En klientkomponent designet for bruk i SMTP-applikasjoner (Simple Mail Transfer Protocol), som gir støtte for autentisering, MIME-koding og -dekoding og støtte for flere byte-tegn.

TIdSNTP

En klientkomponent designet for å gi SNTP (Simple Network Time Protocol) - en tidstjeneste. Kan brukes til å koble til en hvilken som helst tidstjeneste for å bestemme gjeldende dato og klokkeslett.

TIdSimpleServer

Serverkomponent som gir en lett TCP-server. Lar deg organisere en punkt-til-punkt-tilkobling. Den brukes til å lage servere med en enkelt bruker, det vil si at den kun kan betjene én tilkobling om gangen. I motsetning til TIdTCPServer-komponenten, skaper den ikke sekundære prosesser når man venter på forespørsler fra klienter og når disse forespørslene behandles. Med andre ord, hvis serveren betjener en forespørsel fra en klient, og på det tidspunktet en annen klient kontakter den for å koble til, vil den bli blokkert til slutten av behandlingen av den første forespørselen.

TIdTelnet og TIdTelnetServer

Klientkomponenten brukes til å organisere eksterne økter på en annen datamaskin, inkludert konsollforhandlinger og autentisering. Kommunikasjonsprotokollen forutsetter tilstedeværelsen av en person som interagerer interaktivt med serveren. Klientkomponenten har ikke skjermstøtte eller terminalemulering, men gir rett og slett en tilkobling til serverdelen. Vanligvis brukes TIdTelnetServer-serverprotokollen til å organisere eksterne databaser med et tekstgrensesnitt for interaktiv interaksjon med klienter.

TIdTime og TIdTimeServer

Klientkomponenten er et alternativ til TIdSNTP-komponenten for tidsbestemmelse. Det er viktig å merke seg at formatene til de to protokollene er forskjellige. TIdTime er basert på RFC 868-formatet (returnerer tiden i den interne UNIX OS-standarden, og utfører alle nødvendige konverteringer). Serverkomponenten fungerer på samme måte som DayTime-serveren. Kan brukes til å implementere en tidstjeneste på lokal datamaskin. Ingen tilleggskode er nødvendig, bare lag en forekomst av TIdTimeServer som vil returnere klokkeslettet til serverdatamaskinens interne klokke.

TIdTrivialFTP og TIdTrivialFTPServer

Disse komponentene er nødvendige for å organisere en enkel filoverføringsprotokoll. Klientkomponenten til denne protokollen brukes til å koble til en forekomst av den tilsvarende serverkomponenten. Protokollen er beregnet på private, lette, lokale tilfeller av filoverføring, for eksempel i lokale nettverk eller for å laste (opplasting) rutingtabeller til rutere. På grunn av de svekkede egenskapene til denne protokollen, anbefales ikke bruken av den ved bruk av autentiseringsalgoritmer eller andre sikkerhetsmekanismer. Hovedformålet med denne protokollen er å overføre filer til en maskinvareenhet med det formål å endre den.

TIdTunnelMaster og TIdTunnelSlave

Servertunnelkomponenter brukes i proxy-servere for å organisere flere logiske forbindelser over en fysisk (tunnel). Disse klassene kan brukes til ulike formål, for eksempel for å organisere en hemmelig forbindelse over ikke-hemmelige kanaler.

TIdWhois og TIdWhoIsServer

Denne klientkomponenten kobles til en hvilken som helst standard Whois-server, slik at du kan få informasjon om domener. Serverkomponenten gir den grunnleggende funksjonaliteten til en NIC-server.

Indy Diverse

Indy Diverse Components-palettsiden inkluderer BASE64, UUE, Quoted Printable og andre vanlige e-postkommunikasjonsformater, kodere (MD2, MD4 og MD5) for kryptografistandarder som brukes til å lagre passord og elektroniske signaturer i en irreversibel (vanskelig å tyde) form, samt mange andre nyttige komponenter og verktøy som ofte brukes i utviklingen av Internett-applikasjoner.

TIdAntiFreeze

På grunn av de blokkbaserte algoritmene til Indy-komponenter, ser det ofte ut til at applikasjonen sitter fast mens tilkoblingen fungerer. For å eliminere bruken av sekundære prosesser (tråder) når du organiserer kommunikasjon for å forhindre at applikasjonen fryser, er det nok å plassere den angitte komponenten på skjemaet.

Komponenten fungerer ved å analysere forespørsler fra TCP/IP-protokollstakken og sende meldinger til applikasjonen under forsinkelsen når eksterne tilkoblinger er blokkert, noe som skaper en illusjon av kjørende kode. Siden komponenten kun påvirker blokkerte tilkoblinger for hovedprosessen, er det ikke nødvendig å bruke TIdAntiFreeze i sekundære prosesser av applikasjonen. Husk at TIdAntiFreeze-komponenten bremser tilkoblinger fordi hovedprosessen med jevne mellomrom avbrytes for å behandle meldinger. Det følger av dette at man må passe på at applikasjonen som utvikles ikke bruker for mye tid på å behandle meldinger, inkludert OnClick, OnPaint, OnResize osv. Til en viss grad kan dette kontrolleres gjennom egenskapene til TIdAntiFreeze-klassen. Bruken av denne komponenten er ikke obligatorisk, men den lar deg løse problemet med å synkronisere tilkoblinger med det visuelle grensesnittet til applikasjonen.

TIdDateTimeStamp

En klasse for å utføre matematikk for dato og klokkeslett knyttet til det faktum at Internett-protokoller bruker forskjellige dato- og klokkeslettformater; i tillegg kan klienter og servere være plassert i forskjellige tidssoner.

TIdIPWatch

Det er en timerbasert komponent som hele tiden overvåker endringer i datamaskinens IP-adresse. Komponenthendelser oppstår når en endring oppdages. Denne komponenten brukes vanligvis til å oppdage om en datamaskin er koblet til Internett eller et annet nettverk. Endringen i IP-adressen i denne situasjonen kan oppstå på grunn av at IP-adressen blir tildelt av DHCP-serveren (Dynamic Host Configuration Protocol) når den kobles til det nye nettverket.

TIdLogDebug

Hensikten med denne komponenten er å avskjære hendelser for enhver klient- eller serverkomponent og plassere en registrering av hendelsen i spesifisert fil. Denne komponenten er veldig nyttig for feilsøking av Indy-komponenter.

TIdMessage

Komponenten brukes i kombinasjon med andre komponenter for å riktig dekryptere eller kode meldinger. Disse kan være POP-, SMTP- og NNTP-komponenter. Klassen støtter MIME-kryptering og dekryptering, multibyte-tegn og ISO-koding.

TIdNetwork Calculator

En av få Indy-komponenter som kan brukes når du bygger applikasjoner. Nettverkskalkulatoren kan brukes til å utføre beregninger på IP-adresser, inkludert nettverksmasker, subnett, nettverksklasser osv.

TIdThreadMgrDefault

Komponenten gir kontroll over sekundære prosesser som standard. Opprettet når en Indy-komponent som støtter prosessbehandling ikke har en forekomst av TIdThreadManager-klassen definert. Komponenten gir bare grunnleggende funksjoner for å administrere sekundære prosesser: opprette og ødelegge dem på forespørsel.

TIdThreadMgrPool

En mer avansert prosessstyringskomponent enn TIdThreadMgrDefault fordi den slår sammen prosesser i stedet for å opprette eller ødelegge dem på forespørsel.

TIdVCard

VCard er den elektroniske ekvivalenten til et visittkort og kan inneholde eierens personlige opplysninger og grafiske data.

TIdIMFDecoder

Designet for å dekode Internett-meldinger. Det er en etterkommer av TIdCoder-klassen, akkurat som alle andre kodekomponenter. TIdCoder-klassen dekoder i henhold til ARPA Internett-tekstmeldingsformatstandard RFS-822, foreslått i august 1982, og USENET meldingsstandard RFC 1036, foreslått i desember 1987.

Komponenten utvider TIdCoder-klassen for å tillate gjenkjenning av RFS-822-format etter header-kontekst, og gir dekryptering-ved-mottak-modus og MIME-kryptering og dekryptering. TIdIMFDecoder-komponenten brukes i TIdMessageClient-klassen for å dekode mottatte og overførte meldinger.

TIdQuotedPrintableEncoder

QuotedPrintableEncoder lar deg dekryptere tekst i spesifisert format. Kan fungere som en frittstående komponent med en spesifisert kodingstype, slik at meldinger som inneholder en ny kodingstype kan overføres.

TIdBase64 Encoder

Implementerer en annen krypteringsalgoritme som gjør det mulig å overføre tegn som ikke kan skrives ut.

TIdUUEncoder

Implementerer en av de første krypteringsalgoritmene, UU-koding. Noen ganger brukt når du sender artikler til en nyhetstjeneste.

TIdXXEncoder

Denne krypteringsmetoden vil neppe noen gang bli brukt. I hovedsak er dette den samme UU-kodingen, men med en annen krypteringstabell.

TIdCoderMD2

Komponenter med forskjellige typer MD (Message Digest) krypteringsalgoritme. De er alle shuffle-baserte, enveis, og har ingen dekrypteringsalgoritmer.

Komponenter av protokollklienter og servere kan brukes til å utvikle server- og klientinternettapplikasjoner, sammen med eller i stedet for grunnleggende (ClientSocket, ServerSocket) og andre komponenter fra Internett- og Fastnet-paletten. Indy-komponenter bruker ikke WebBroker-arkitekturen, og implementerer lavnivåstøtte for Internett-protokoller og tjenester direkte i kildekoden ( kildekoder er vedlagt).

TIdConnectionInterceptOpenSSL og TIdServerInterceptOpenSSL

SSL-protokollen - Secure Sockets Layer, som sikrer hemmelighold og pålitelighet av kommunikasjon mellom to applikasjoner, har to lag. På det lave nivået av en flerlags transportprotokoll (som TCP), er SSL en opptaksprotokoll og brukes til å innkapsle forskjellige protokoller på høyere nivå. Fordelen med SSL er at det er en uavhengig applikasjonsprotokoll, men en protokoll på høyere nivå kan brukes på toppen av SSL.

SSL gir kommunikasjonssikkerhet, som har tre hovedfunksjoner: å tilby en konfidensiell tilkobling; kryptering med offentlig nøkkel(brukes for å bekrefte autentisiteten til adressaten); støtte for pålitelighet av dataoverføring.

• Symmetrisk kryptografi brukes til å kryptere data (f.eks. DES, RC4 osv.).
• Digital signatur leveres ved bruk av asymmetrisk offentlig nøkkelkryptering (for eksempel RSA, DSS, etc.).
• Pålitelighet av kommunikasjon, meldingstransport inkluderer å sjekke integriteten til meldingen gjennom MAC-korreksjonskoder, sikre hash-funksjoner (f.eks. SHA, MD5, etc.) ved hjelp av MAC-beregninger.

I kombinasjon med HTTP og serverautentisering gir SSL de nødvendige krypteringsfunksjonene og opprettholder videre den etablerte forbindelsen ved å krysssjekke identiteten til webserveren osv. Det er viktig å forstå at SSL kun beskytter kommunikasjon under dataoverføring og ikke erstatter andre sikkerhetsmekanismer.

TIdConnectionInterceptOpenSSL- og TIdServerInterceptOpenSSL-komponentene gir både klient- og server-side tilkoblinger ved hjelp av SSL-protokollen. Det skal bemerkes at TIdConnectionInterceptOpenSSL- og TIdServerInterceptOpenSSL-komponentene kun er tilgjengelige i Delphi 6, og ikke i Kylix. Dette skyldes kompleksiteten til protokollen, som i tilfelle av en Windows-implementering er basert på operativsystemfunksjoner.

Eksempler på bruk av Indy-komponenter finnes i /Delphi6/Demos/Indy-katalogene. Totalt inneholder Indy-biblioteket i versjon 8.0 69 komponenter. Det er oppgitt at i versjon 9.0 vil det angitte biblioteket inneholde 86 komponenter. Alle komponentene er samlet og inkludert i både Delphi 6 og Kylix, noe som gjør at de kan brukes til å utvikle applikasjoner på tvers av plattformer. Alle Indy-komponenter støtter multithreading.

Indy-komponentene implementerer nesten all funksjonaliteten som finnes i Internett- og Fastnet-komponentene, som tydelig vises i tabellen.

	Fastn et komponenter	Indy komponenter	Formål med komponenter
1	TserverSocket, TClientSocket	TIdTCPserverSocket, TIdTCPClientSocket	Interaksjon mellom to datamaskiner (klient og server) ved hjelp av TCP/IP-protokollen
2	TNMDayTime	TIdDayTime, TIdDayTimeServer	Spør serveren for gjeldende tidspunkt
3	TNMEcho	TIdEcho, TIdEchoServer	Brukes til å kommunisere med responsserveren
4	TNMFinger	TIdFinger, TIdFingerServer	Brukes til å hente informasjon om brukeren fra en Internett-søkeserver
5	TNMFTP	TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer	Gi filoverføring ved hjelp av FTP-protokoll
6	TNMHTTP	TIdHTTP, TIdHTTPServer	Bruk HTTP-protokoll for datautveksling
7	TNMMsgServ, TNMMsg		Brukes til å formidle enkelt tekstmeldinger fra klient til server
8	TNMNNTP	TIdNNTP, TIdNNTPServer	Støtter datautveksling med nyhetsserver
9	TNMPOP3	TIdPOP3	Brukes til å motta e-post fra en e-postserver som bruker POP3-protokollen
10	TNMSMTP	TIdSMTP	Brukes til å sende e-post via e-postserver Internett
11	TNMSrm, TNMSrmServ		Sender binære data skrevet til en strøm ved hjelp av TCP/IP-protokollen
12	TNMUDP	TIdUDP, TIdUDPServer	Overfør data ved hjelp av UDP-protokollen
13	TpowerSock, TNMGeneralServer		Komponentinnkapslede klasser som er grunnlaget for å skrive dine egne klienter (Powersock) og servere (NMGeneralServer)
14	TNMUUprosessor	TIdUUEkoder, TIdUUDekoder	Utfør omkoding binære filer til MIME- eller UUENCODE-format
15	TNMURL		Konverterer strenger til HTML-format og utfører omvendt konvertering

Unntakene er klasser som TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, som enten implementerer foreldede protokoller eller har funksjonalitet implementert i en stor gruppe alternative klasser.

Men i motsetning til forgjengerne - Internett- og Fastnet-komponentene, inneholder Indy rikere serverkomponenter og komponenter for datatranskoding og kryptering, samt autentiseringsstøtte (Indy Misc-palett). Som det fremgår av tabellen ovenfor, leveres hovedprotokollene og tjenestene ikke bare av klienten, men også av serverkomponenter. Dette er tidstjenester, responstjenester, innhenting av brukerinformasjon, samt HTTP, NNTP, UDP-protokoller og til og med den enkleste versjonen av FTP.

Noen eksempler på bruk av Indy-komponenter

I Indy-komponenter i Delphi er IP-adressen definert i Host-egenskapen, vanligvis bare i klientapplikasjoner. Server-vertsbaserte komponenter har metoder som lar deg starte eller stoppe polling av den korresponderende porten - for eksempel endring av Active-egenskapen til IdTCPServer-komponenten starter eller stopper polling av den tilsvarende porten. Når forbindelsen mellom klienten og serveren er etablert, kan dataoverføringen begynne.

Indy-komponenter legger stor vekt på sikkerhet og pålitelighet når du arbeider med data. For eksempel har IdTCPClient-komponenten Connect- og Disconnect-metoder. Ved å bruke en programmeringsteknikk som koden nedenfor fra klientsiden:

med TCPClient begynner Connect; prøv lstMain.Items.Add(ReadLn); til slutt Koble fra; slutt; slutt;

og bruk av Connection-egenskapen som sendes som en parameter til AThread-forekomsten av TIdPeerThread-klassen fra serversiden:

med AThread.Connection begynner WriteLn("Hei fra Basic Indy Server-server."); Koble fra; slutt;

du kan stole på enten normal utførelse av tilkoblingen eller riktig feilhåndtering.

Legg merke til ReadLn- og WriteLn-metodene til de tilsvarende klassene - de ligner standard Pascal I/O-setninger. Dette er en hyllest til UNIX-programmeringsteknikken, hvor de fleste systemoperasjoner utføres ved å lese og skrive til de tilsvarende filene.

Akkurat som Fastnet-komponenter, har Indy-komponentklasser hendelser som kan brukes til å gi hendelsesadministrasjon. Du kan for eksempel sørge for at en melding vises på et skjema når du kobler til en klient:

prosedyre TForm1.IdECHOServer1Connect(ATråd: TIdPeerThread); begin lblStatus.caption:= "[ Betjener klient ]"; slutt;

Indy leverer komponenter som implementerer protokoller med klient- og serverdeler som er unike for dette biblioteket. TIdGopherServer- og TIdGopher-komponentene, takket være metodene GetExtendedMenu, GetFile, GetMenu, GetTextFile på klientsiden og ReturnGopherItem, SendDirectoryEntry på serversiden, hjelper til med å vise filer forskjellige typer, inkludert de som er merket som skjulte, samt kataloger på ekstern datamaskin(ligner på hvordan dir *.*-kommandoen gjør det i MS-DOS-operativsystemet).

Ved å bruke IdSMTP- og IdMessage-komponentene kan du enkelt lage din egen webapplikasjon som kan sende e-post ved hjelp av SMTP-protokollen.

I dette tilfellet er IdMessage-klassen (en av 23 komponenter fra Indy Misc-siden) ansvarlig for å generere meldingen, som følger av navnet, og IdSMTP er for å organisere forbindelsen med e-postserveren.

Teknologien som brukes i Indy bruker låsende lese- og skriveoperasjoner. Enhver Connect-operasjon som brukes i Indy venter på at tilkoblingen skal fullføres. Når du arbeider med Indy-klientkomponenter, må du vanligvis gjøre følgende:

• be om en tilkobling til serveren;
• foreta lese- og skriveforespørsler til serveren (avhengig av typen server utføres trinnet én gang eller gjentas mange ganger);
• avslutte tilkoblingen til serveren og koble fra.

Indy-komponenter er designet for å gi et ultrahøyt abstraksjonsnivå. Forviklingene og detaljene i TCP/IP-stabelen er skjult for programmereren slik at han kan fokusere på oppgaven som skal utføres.

Følgende lille eksempel viser en typisk klientbønneøkt:

med IndyClient begynner Host:= "zip.pbe.com"; // Vert for å ringe Port:= 6000; // Port for å ringe serveren på Connect; prøv // Koden din går her til slutt Koble fra; slutt; slutt;

I eksemplet, selv om tilkoblingen til serveren ikke er etablert, vil tilkoblingen bli avsluttet på grunn av bruken av try-finally-setningen.

Indys serverkomponenter beskriver en rekke servermodeller som kan brukes avhengig av dine behov og protokollen du bruker.

TIdTCPServer er den mest brukte serverkomponenten, som skaper en sekundær prosess uavhengig av hovedapplikasjonsprosessen. Den opprettede prosessen venter på innkommende forespørsler fra potensielle kunder. En individuell sekundær prosess opprettes for hver klient hvis forespørsel den svarer på. Hendelser som oppstår under vedlikeholdsprosessen er relatert til konteksten til de tilsvarende prosessene.

Med andre ord, for hver klienttilkobling bruker TIdTCPServer-klassen en unik sekundær tråd ved å kalle den trådens OnExecute-hendelsesbehandler. Den formelle parameteren til OnExecute-metoden er en referanse til en forekomst av Athread-klassen som tilsvarer den opprettede tråden. Connection-egenskapen til denne klassen er en referanse til TIdTCPConnection-klassen, en forekomst av denne er opprettet for å behandle klientforespørselen. TIdTCPConnection støtter lesing og skriving over forbindelsen, i tillegg til å etablere og avslutte en kommunikasjonsøkt.

UDP-protokollen fungerer uten først å etablere en forbindelse med serveren (hver sendte pakke er et uavhengig sett med data, og ikke en del av en større økt eller tilkobling). Mens TIdTCPServer skaper separate tråder for hver tilkobling, bruker TIdUDPServer enten en hovedtråd eller en enkelt sekundær tråd som håndterer alle UDP-protokollforespørsler. Når TIdUDPServer er aktiv, opprettes en tråd for å lytte etter innkommende UDP-pakker. For hver pakke som mottas, heves en OnUDPRead-hendelse enten på hovedtråden eller i konteksten til lyttetråden, avhengig av verdien til ThreadedEvent-egenskapen. Når ThreadedEvent evalueres til False, skjer hendelsen på hovedtråden, ellers skjer den på lyttetråden. Mens hendelsen behandles, blokkeres andre serveroperasjoner. Derfor er det viktig å sikre at OnUDPRead-prosedyrene kjører så raskt som mulig.

Hvis du trenger å opprette en ny klientapplikasjon for en eksisterende server ved å bruke en eksisterende protokoll, er oppgaven din utelukkende å utvikle og feilsøke klientapplikasjonen. Men når du skal utvikle både klient og serverapplikasjon Enten vi bruker en eksisterende eller en ny protokoll, står vi overfor det klassiske "kylling og egg"-problemet. Hvor skal jeg begynne å programmere - fra klienten eller fra serveren?

Det er klart at både klienten og serveren må opprettes til slutt. For mange applikasjoner, spesielt de som bruker en tekstbasert protokoll (som HTTP), er det lettere å begynne å bygge applikasjonen ved å designe serveren. Og for feilsøking er det en praktisk klient som allerede eksisterer. Dette er en Telnet-konsollapplikasjon som er tilgjengelig på både Windows og UNIX.

Hvis du skriver konsollen telnet kommando 127.0.0.1 80 med IP-adressen til den lokale datamaskinen og portnummer 80, som brukes som standard av webservere, vil applikasjonen svare med teksten vist i fig. 6, for Windows 2000 OS og IIS 5.0.

For å lage den enkleste serveren med Indy-komponenter trenger du:

Hvis du trenger å designe en server som ikke bare vil informere klientene sine riktig når forbindelsen er tapt, men også gi dem informasjon om feilsituasjoner som har oppstått, bruk try-except-setningen i stedet for try-finally - for eksempel som vist i følgende eksempel:

prosedyre TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: streng; begynn med AThread.Connection prøv prøv s:= ReadLn; // Utfør oppgaven til serveren her // hvis ingen unntak oppstår, // skriv ut serverens svar. //prøve bortsett fra til slutt Koble fra;

Dette lille eksemplet viser trinnene for å lage en enkel tekstserver, samt hvordan du feilsøker den.

Serveren beskrevet ovenfor er et typisk eksempel på organisering av moderne distribuert databehandling.

Funksjoner for å lage flerlagsapplikasjoner

Nylig har flere servere blitt brukt i økende grad for å tilfredsstille klientforespørsler. En server av denne typen, etter å ha mottatt en klientforespørsel og delvis forberedt den for videre behandling, kontakter en annen server og sender den transformerte forespørselen eller forespørslene. Andrelagsserveren kan på sin side kommunisere med andre servere. Dermed kan vi snakke om en flerlags serverarkitektur.

Deretter vil vi lage en datatilgangsserver hvis formål er å returnere data fra databasen. Denne serveren leser eller skriver ikke direkte til databasefilene. I stedet kommuniserer den med databaseserveren på jakt etter dataene som kreves av klienten.

Så vi begynner å utvikle en applikasjon med en trelagsarkitektur. For å lage en databaseserver med Indy-komponenter trenger du:

1. Opprett et nytt prosjekt.
2. Plasser en forekomst av TIdTCPServer-komponenten fra Indy Servers-paletten på hovedformen til prosjektet.
3. Sett DefaultPort-egenskapen til TIdTCPServer1-klasseforekomsten til 6001 (det anbefales å tilordne store verdier for å unngå duplisering av portnumre på tvers av forskjellige applikasjoner), og sett Active-egenskapen til true.
4. Legg til en ny modul til prosjektet ved å velge Fil | Ny | Data Module, og plasser forekomster av SQLConnection- og SQLDataSet-komponentene på den fra dbExpress-fanen på komponentpaletten.
5. Sett ConnectionName-egenskapen til SQLConnection-klassen til IBLocal og LoginPrompt til False. Hvis du ikke har konfigurert IBLocal på databasen medarbeider.gdb, fullfør denne prosedyren først.
6. Sett SQLConnection-egenskapen til SQLDataSet-klassen til SQLConnection1 og tilordne egenskapen til CommandText SQL-setning: velg CUSTOMER, CONTACT_FIRST, CONTACT_LAST fra CUSTOMER hvor CUST_NO = :cust.

Serge Dosyukov Mike Pham

Denne artikkelen viser deg hvordan du oppretter en frittstående webtjeneste ved å bruke Indy-settet og Delphi 7, og hvordan du bruker Indy-settet til å støtte Delphi 7 SOAP-baserte webtjenester. Bak tilleggsinformasjon For informasjon om å lage webtjenester, se Nick Hodges' utmerkede artikkel på Borland-fellesskapets nettsted: Shakespeare on the Web.

Før eller siden må du kanskje opprette en server som er en frittstående HTTP-server og støtter webtjenester. For eksempel vil du kanskje lage en SOAP-basert applikasjonsserver for en n-tier applikasjon bygget ved hjelp av Delphi.

Introduksjon

Delphis online hjelp gir utmerket sekvensiell instruksjon om hvordan du oppretter en webtjeneste, MIDAS-server (COM, DCOM-modell), men det er praktisk talt ingen informasjon om å lage en frittstående n-tier MIDAS-applikasjon basert på SOAP-protokollen.

Tidligere utgitt av Dave Nottage. Denne artikkelen beskrev ideen om hvordan du oppretter en webtjeneste i Delphi 6 med SOAP-støtte og muligheten til å publisere SOAP-grensesnitt til Datamodulen, det vil si at denne artikkelen tillot deg å lære hvordan du lager din egen n-tier MIDAS-systemer.

Borlands Delphi 7 og det nye Indy-settet har innebygd støtte for denne funksjonaliteten.

Til tross for innebygd støtte er denne funksjonen imidlertid ikke dokumentert.

Nylige innlegg på Borland-nettkonferansen og nettsøk ved hjelp av Google-serveren har gjort det mulig for forfatterne å utvikle en måte å konvertere eksisterende kode fra Delphi 6 til Delphi 7. Men alt har sin tid.

hovedide

Denne artikkelen er første del av en tredelt serie. Den beskriver hovedbestemmelsene. Den andre og tredje delen vil bli viet til noen problemer og måter å løse dem på. La oss begynne å beskrive hovedideen.

• være en frittstående HTTP-server;
• bruk Indy som plattform;
• støtte publisering via SOAP-protokoll;
• være i stand til å publisere SOAP DataModules, som vil tillate deg å lage din egen n-tier server basert på SOAP/HTML.

HTTP-server og SOAP

Mange kjenner Indy og har brukt THTTPServer-komponenter før. Det er enkelt å sette denne komponenten på et søknadsskjema, men hvordan får du den til å støtte SOAP? I katalogen "C:Program FilesBorlandDelphi7SourceIndy" kan du finne filen IdHTTPWebBrokerBridge.pas. Dette er akkurat det du trenger.

Denne filen er ikke en del av den kjørbare Indy-filen, så du må inkludere den i ditt nåværende prosjekt som en standard prosjektfil. (For å kompilere prosjektet trenger du også filen IdCompilerDefines.inc.) Disse filene må kopieres til gjeldende prosjektkatalog. Kodeendringer kan være nødvendig for å øke hastigheten, så det er best å holde disse filene atskilt fra Indy-distribusjonen.

Det følgende beskriver implementeringen av en erstatningskomponent fra THTTPServer, utvidet til å støtte SOAP-pakker, kalt TIdHTTPWebBrokerBridge. Denne konstruksjonen er en klasse som arver fra TCustomHTTPServer og støtter grunnleggende forespørselsbinding.

Fordi denne klassen ikke er tilgjengelig fra paletten, må du definere den som et vanlig objekt når du kjører koden.

Dette objektet kan brukes på nøyaktig samme måte som en vanlig THTTPServer, med unntak av de tilleggsegenskapene som muliggjør drift med SOAP.
La oss imidlertid først se på å forberede den nødvendige koden.

WebBroker og Indy

For de som har laget webtjenester før, vet du at du bruker WebBroker. Delphi 7, som Delphi 6, bruker WebBroker-arkitekturen for å støtte SOAP.

Derfor må du lage en modul TWebModule og plasser følgende tre komponenter i den: THTTPSoapDispatcher, THTTPSoapPascalInvoker og TWSDLHTMLPublish. Alle er tilgjengelige fra WebServices-fanen i komponentpaletten. Etter å ha koblet SOAPDispatcher med SOAPPascalInvoker, er søknadsskjemaet klart. Sluttresultatet skal se omtrent ut som følgende figur:

(modul uWebModule.pas)

Det er best å la alt være som det er, siden det ikke er nødvendig å endre eller utføre noen egendefinert kode for dette skjemaet.

WebModule og Indy

La oss gå videre til den andre delen av koden som trengs for å implementere HTTP-serveren.

Som du kan se, har TIdHTTPWebBrokerBridge en RegisterWebModuleClass-metode, som lar deg registrere din egen WebModule og gjøre den tilgjengelig for serveren.

Derfor, etter å ha opprettet fServer-serverobjektet, trenger du bare å kalle klassen fServer.RegisterWebModuleClass (TwmSOAPIndy).

Merk. I en normal implementering av TIdHTTPWebBrokerBridge vil et TwmSOAPIndy-objekt bli opprettet hver gang en forespørsel mottas. Dette er åpenbart ikke nødvendig. Derfor kan klassen endres for å gi permanent opprettelse av dette objektet så lenge Server-objektet eksisterer. Det anbefales at du refererer til klasfor mer informasjon.

Er serveren klar?

Introduksjon til Indy

Introduksjon til Indy
Skrevet av Chad Z. Hower
Hjemmeside: http://www.atozedsoftware.com
Oversettelse: Anatoly Podgoretsky
introduksjon
Jeg skrev denne artikkelen når gjeldende versjon var Indy 8.0. Mye av denne artikkelen er anvendelig og veldig nyttig i fremtidige versjoner av Indy. Hvis du likte denne artikkelen og vil lese flere dybdeartikler, så sjekk ut boken Indy in Depth.
Indy kjører i blokkeringsmodus
Indy bruker blokkerende stikkontakter. Blokkeringsmodus ligner på å lese-skrive filer. Ved lesing eller skriving av data returnerer ikke funksjonen kontroll før operasjonen er fullført. Forskjellen fra å jobbe med filer er at samtalen kan ta lengre tid, siden de forespurte dataene ikke eksisterer ennå, dette avhenger av hastigheten som nettverket eller modemet ditt fungerer med.
For eksempel kalles en metode ganske enkelt og venter til kontrollen returneres til melderen. Hvis samtalen var vellykket, vil kontrollen bli returnert fra metoden hvis en feil oppstår, vil et unntak bli reist.
Lockdown er ikke dødelig
På grunn av blokkeringsmodusen har vi blitt slått mange ganger av våre motstandere, men blokkeringsmodusen er ikke djevelen.
Problemet dukket opp etter portering av Winsock til Windows. I Unix ble problemet typisk løst ved forking (ligner på multi-threading, men med separate prosesser i stedet for tråder). Unix-klienter og demoner måtte dele prosessene som skulle kjøres og bruke blokkeringsmodus. Windows 3.x kunne ikke parallellisere og støttet ikke mye tråding. Ved å bruke et blokkerende grensesnitt frøs brukergrensesnittet og gjorde at programmer ikke responderte. Derfor ble ikke-blokkerende moduser lagt til WinSock, noe som tillater Windows 3.x med sine begrensninger å bruke Winsock uten å blokkere hoved- og eneste tråden i programmet. Dette krevde forskjellig programmering, og Microsoft og andre utskjelte blokkeringsmoduser lidenskapelig for å dekke over manglene til Windows 3.x.
Så kom Win32, som var i stand til å støtte multi-threading. Men på dette tidspunktet var hjernen deres allerede rotete (det vil si at utviklerne anså blokkering av stikkontakter for å være djevelens skapelse), og det var allerede vanskelig å endre det de hadde gjort. Derfor fortsetter bakvaskelsen av blokkeringsregimer.
I virkeligheten har Unix bare blokkerende stikkontakter. Blokkeringskontakter har også sine fordeler og er mye bedre for flertråding, sikkerhet og andre aspekter. Noen utvidelser er lagt til Unix for ikke-blokkerende stikkontakter. Imidlertid fungerer de veldig annerledes enn på Windows. De er også ikke-standardiserte og ikke veldig vanlige. Blokkeringskontakter i Unix brukes i nesten alle tilfeller, og vil fortsatt brukes.
Fordeler med blokkeringsmodus·Enklere å programmere - Blokkeringsmoduser er lettere å programmere. All brukerkode kan være på ett sted og utføres i en naturlig, sekvensiell rekkefølge. ·Enklere å portere til Unix - Siden Unix bruker blokkeringskontakter, er bærbar kode lettere å skrive i dette tilfellet. Indy bruker dette faktum til å skrive enhetlig kode. ·Det er mer praktisk å jobbe med tråder - Siden blokkeringssokler har en sekvens ervervet av arv, så de er veldig enkle å bruke i tråder.
Ulemper med blokkeringsmodus · Brukergrensesnittet fryser i klienter - En blokkerende socket call returnerer ikke kontroll før den har fullført oppgaven. Når et slikt anrop foretas på applikasjonens hovedtråd, kan ikke applikasjonen behandle brukermeldinger. Dette fører til at brukergrensesnittet fryser, vinduer ikke oppdateres og ingen andre meldinger behandles før kontrollen er returnert fra blokkeringskontakten.
TIDAntiFreeze-komponent
Indy har en spesiell komponent som løser problemet med å fryse brukergrensesnittet. Bare legg til én TIDAntiFreeze-komponent hvor som helst i applikasjonen din, og du kan foreta blokkeringsanrop uten å fryse brukergrensesnittet.
TIdAntiFreeze kjører på en intern timer utenfor anropsstakken og kaller Application.ProcessMessages når tidsavbruddet utløper. Eksterne anrop til Indy fortsetter å blokkere og fungerer derfor nøyaktig på samme måte som uten å bruke TIdAntiFreeze-komponenten. Ved å bruke TIdAntiFreeze kan du få alle fordelene med å blokkere stikkontakter, uten noen av ulempene.
Kode tråder (Threading)
Med blokkerende stikkontakter brukes kodestrømmer nesten alltid. Ikke-blokkerende stikkontakter kan også bruke gjenger, men dette krever noe tilleggsbehandling og deres fordeler i dette tilfellet går tapt sammenlignet med blokkerende stikkontakter.
Fordeler med tråder·Angi prioriteter - Prioritetene til individuelle tråder kan konfigureres. Dette gjør at individuelle oppgaver kan tildeles mer eller mindre CPU-tid. ·Innkapsling - Hver tilkobling kan inneholde noen form for et grensesnitt med en annen tilkobling. ·Sikkerhet - Hver tråd kan ha forskjellige sikkerhetsattributter. ·Flere prosessorer - gir en fordel på systemer med flere prosessorer. ·Ingen behov for serialisering - gir full samtidighet. Uten mye tråding må alle forespørsler behandles i én tråd. Derfor må hver oppgave deles opp i små biter slik at den kan fungere raskt. Mens en blokk kjører, er alle andre tvunget til å vente på at den er ferdig. På slutten av en blokk utføres den neste og så videre. Med multithreading kan hver oppgave programmeres som en enkelt enhet og operativsystem fordeler tid mellom alle oppgaver.
Avstemningstråder
Å lage og ødelegge tråder er svært ressurskrevende. Dette er en spesielt vanskelig oppgave for servere som har kortvarige tilkoblinger. Hver server oppretter en tråd, bruker den i kort tid, og ødelegger den deretter. Dette resulterer i at tråder opprettes og slettes svært ofte. Et eksempel på dette er en webserver. En enkelt forespørsel sendes og et enkelt svar returneres. Når du bruker en nettleser, kan hundrevis av tilkoblinger og frakoblinger oppstå når du ser på et hvilket som helst nettsted.
Avstemningstråder kan rette opp denne situasjonen. I stedet for å opprette og ødelegge tråder på forespørsel, velges tråder fra en liste over ubrukte, men allerede opprettede tråder fra bassenget. Når en tråd ikke lenger er nødvendig, blir den returnert til bassenget i stedet for å bli ødelagt. Tråder i bassenget er merket som ubrukte og bruker derfor ikke CPU-tid. For enda større forbedringer kan tråder dynamisk tilpasse seg dagens behov til systemet.
Indy støtter trådmåling. Trådpoolen i Indy er tilgjengelig gjennom TIdThreadMgrPool-komponenten.
Mange tråder
En tungt lastet server kan kreve hundrevis eller til og med tusenvis av tråder. Det er en vanlig oppfatning at hundrevis og tusenvis av tråder kan drepe systemet ditt. Dette er en falsk tro.
På de fleste servere venter tråder på data. Mens du venter på en blokkerende samtale, er tråden inaktiv. I en server med 500 tråder kan bare 50 være aktive samtidig.
Antall tråder som kjører på systemet ditt kan overraske deg. Med et minimum antall kjørende servere og spesifisert kjører applikasjoner systemet mitt har opprettet 333 tråder, selv med 333 tråder er CPU bare 1% lastet. Tungt lastet IIS server(Microsoft Internet Information Server) kan lage hundrevis og tusenvis av tråder.
Tråder og globale seksjoner
Med flere tråder må du sikre dataintegritet når du får tilgang til den. Dette kan være vanskelig for programmerere som ikke har jobbet med tråder. Men generelt trenger ikke de fleste servere å bruke globale data. De fleste servere utfører isolerte funksjoner. Hver tråd utfører sin egen isolerte oppgave. Globale lese/skrive-seksjoner er en funksjon i mange flertrådede applikasjoner, men er ikke typiske for servere.
Metodikk Indy
Indy er forskjellig fra andre Winsock-komponenter du er vant til. Hvis du har jobbet med andre komponenter, da den beste løsningen vil glemme hvordan de fungerer. Mange andre komponenter bruker ikke-blokkerende (asynkrone) anrop og fungerer asynkront. De må reagere på hendelser, lage en tilstandsmaskin og utføre hyppige venteløkker.
For eksempel, med andre komponenter, når du ringer en tilkobling, må du enten vente på at tilkoblingshendelsen oppstår eller vente i en sløyfe på at en egenskap indikerer at tilkoblingen har skjedd. Med Indy kan du ringe Connect-metoden og vente til den kommer tilbake. En refusjon vil bli utstedt hvis tilkoblingen er vellykket eller et unntak gjøres hvis det er et problem. Derfor er det å jobbe med Indy veldig likt å jobbe med filer. Indy lar deg legge all koden din på ett sted, i stedet for å spre den over forskjellige hendelser. I tillegg er Indy veldig enkelt og mest praktisk når du arbeider med tråder.
Hvor annerledes er Indy?
Kort oversikt·Bruker blokkering av samtaler ·Ikke hendelsesorientert - det er hendelser, men de brukes til informasjonsbehov og er egentlig ikke nødvendige. ·Designet for tråder - Indy er designet for tråder, men kan brukes uten tråder. Sekvensiell programmering
Detaljert gjennomgang
Indy bruker ikke bare blokkeringsanrop (synkrone), men fungerer også slik. En typisk Indy-økt ser slik ut:
med IndyClient begynner
Koble; Prøve
//Gjør tingene dine her
til slutt Koble fra; slutt;
slutt;
Med andre komponenter ser det slik ut:
prosedyre TFormMain.TestOnClick(Sender: TComponent);
begynne
med SocketComponent begynner
Koble; prøve
mens den ikke er tilkoblet, begynner
hvis IsError så begynn
Avbryte;
slutt;

OutData:= "Data å sende";
mens lengde(OutData) > 0 begynner
Application.ProcessMessages;
slutt;
til slutt Koble fra; slutt;
slutt;
slutt;
prosedyre TFormMain.OnConnectError;
begynne
IsError:= Sant;
slutt;
prosedyre TFormMain.OnRead;
var
i: Heltall;
begynne
i:= SocketComponent.Send(OutData);
OutData:= Copy(OutData, i + 1, MaxInt);
slutt;
Mange komponenter gjør ikke en veldig god jobb med å isolere programmereren fra stabelen. Mange komponenter, i stedet for å isolere brukeren fra kompleksiteten i stabelen, overlater ganske enkelt brukeren til det eller gir en innpakning over stabelen.
Indy spesiell måte
Indy er designet fra grunnen av for å være flertrådet. Å bygge servere og klienter i Indy ligner på å bygge servere og klienter i Unix. Unix-applikasjoner kaller vanligvis stabelen direkte med lite eller ingen abstraksjonslag.
Vanligvis har Unix-servere en eller flere lytteprosesser som overvåker innkommende klientforespørsler. For hver klient som skal betjenes, a ny prosess. Dette gjør programmeringen enkel, hver prosess for kun én klient. Hver prosess kjører i sin egen sikkerhetskontekst, som settes av lytteprosessen eller prosessen basert på eksisterende rettigheter, identitet eller andre ting.
Indy-servere fungerer omtrent på samme måte. Windows, i motsetning til Unix, kan ikke multiplisere prosesser godt, men det fungerer bra med tråder. Indy-servere oppretter en egen tråd for hver klienttilkobling.
Indy-servere tildeler en lyttetråd som er atskilt fra programmets hovedkodetråd. Lyttetråden lytter etter innkommende forespørsler fra klienter. For hver klient den svarer på, opprettes en ny tråd for å betjene klienten. Relevante hendelser blir deretter betjent i sammenheng av denne strømmen.
Indy kundeanmeldelse
Indy er designet for å gi et svært høyt abstraksjonsnivå. Intrikaten og detaljene til TCP/IP-stakken er skjult for programmereren Vanligvis ser en typisk klientøkt i Indy slik ut:
med IndyClient begynner
Host:= "zip.pbe.com"; // Vert å ringe
Port:= 6000; // Port å ringe serveren på
Koble; Prøve
//Gjør tingene dine her
til slutt Koble fra; slutt;
slutt;
Indy server oversikt
Indy-serverkomponenter lager en lyttetråd som er isolert fra hovedprogramkodetråden. Lyttetråden lytter etter innkommende forespørsler fra klienter. For hver klient den svarer på, opprettes en ny tråd for å betjene klienten. De tilsvarende hendelsene blir deretter behandlet i sammenheng med den tråden.

Praktiske eksempler
Følgende eksempler skal hjelpe deg med å komme i gang med komponenter for lett å bruke, men for å demonstrere eksempler laget som enkle applikasjoner. Noen prosjekter er laget for å demonstrere ulike situasjoner. Disse eksemplene er også tilgjengelige for nedlasting som zip-filer.
Merknad fra oversetteren: lenken på siden fungerer ikke.
Eksempel 1 - Postnummerbekreftelse
Det første prosjektet er gjort så enkelt som mulig. Søk etter postnummer, klienten spør serveren hvilken by og delstat det angitte postnummeret tilhører.
For de som bor utenfor USA og ikke vet hva et postnummer er, er det et postnummer som angir leveringsstedet. Postnummer består av 5 sifre.
Protokoll
Det første trinnet i å bygge en server og klient er å utvikle en protokoll. For standardprotokoller er dette definert av den tilsvarende RFC. For postnummer er protokollen definert nedenfor.
De fleste kommunikasjonsprotokoller opererer i tekstmodus. Utveksling betyr at en kommando blir overført, og som svar, status og eventuelt data. Protokollene er ikke begrenset til utveksling, men ren tekst brukes fortsatt. Protokollen for å fastsette postnummer er også tekstbasert. Ren tekst gjør protokoller enkle å feilsøke og lar forskjellige programmeringsspråk og operativsystemer kommunisere.
Etter tilkobling sender serveren en hei-melding, og godtar deretter kommandoen. Denne kommandoen kan være "Postnummer x" (hvor x er postnummeret) eller "Avslutt". Som svar på ZipCode-kommandoen sendes et svar i form av en enkelt linje med svaret eller tom linje hvis koden ikke blir funnet. Avslutt-kommandoen får serveren til å lukke tilkoblingen. Serveren kan godta flere kommandoer før Avslutt-kommandoen sendes.
Serverkildekode

enhet ServerMain;

grensesnitt

bruker

type

TformMain = klasse(TForm)

IdTCPServer1: TIdTCPServer;

prosedyre FormCreate(Sender: TObject );

prosedyre FormDestroy(Sender: TObject );

prosedyre IdTCPServer1Connect(ATråd: TIdPeerThread) ;

privat

Postnummerliste: TStrings;

offentlig

slutt ;

FormMain: TformMain;

gjennomføring

(R*.DFM)

prosedyre TformMain.IdTCPServer1Connect (AThread: TIdPeerThread) ;

begynne

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

slutt ;

SCommand: streng ;

begynne

SCommand:= ReadLn ;

slutt ;

slutt ;

slutt ;

prosedyre TformMain.FormCreate (Sender: TObject );

begynne

ZipCodeList:= TStringList.Create ;

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

slutt ;

prosedyre TformMain.FormDestroy (Avsender: TObject );

begynne

ZipCodeList.Free ;

slutt ;

slutt.

De eneste Indy-spesifikke delene i prosjektet er IdTCPServer1-komponenten, IdTCPServer1Connect og IdTCPServer1Execute-metodene.
Skjemaet inneholder IdTCPServer1-komponenten av typen TIdTCPServer. Følgende egenskaper er endret: ·Active = True - Etter at programmet starter, lytter serveren. ·DefaultPort = 6000 - Portverdi for dette prosjektet. Serveren lytter etter klientforespørsler på denne porten.
IdTCPServer1Execute-metoden er knyttet til serverens OnExecute-hendelse. OnExecute-hendelsen oppstår etter at klienttilkoblingen er akseptert. OnExecute-arrangementet er forskjellig fra andre hendelser du kjenner. OnExecute kjører i sammenheng med en tråd. Trådhendelsen blir hevet og gitt AThread-argumentet sendt til metoden. Dette er viktig fordi flere OnExecute-hendelser kan utføres samtidig. Dette gjøres slik at serveren kan fungere uten å lage en ny komponent. Det finnes også metoder som kan overstyres ved konstruksjon av arvinger.
OnConnect-hendelsen utløses etter at tilkoblingen er akseptert og en tråd er opprettet for den. I denne serveren brukes dette til å sende en velkomstmelding til klienten. Om ønskelig kan dette også gjøres i OnExecute-hendelsen.
OnExecute-hendelsen kan utløses flere ganger til tilkoblingen blir frakoblet eller tapt. Dette eliminerer behovet for å sjekke tilkoblingen for frakobling eller tap i en sløyfe i en hendelse.
IdTCPServer1Execute bruker to grunnleggende funksjoner, ReadLn og WriteLn. ReadLn leser en streng fra tilkoblingen, og WriteLn sender en streng til tilkoblingen.
sCommand:= ReadLn;
Koden ovenfor tar en streng fra klienten og plasserer den i den lokale sCommand-strengvariabelen.

hvis SameText (sCommand, "QUIT" ) så begynn

end else hvis SameText (Copy (sCommand, 1 , 8 ), "Pistkode " ) og deretter begynne

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

slutt ;

Deretter sjekkes sCommand for gyldige kommandoer.
Hvis kommandoen er "Avslutt", utføres frakobling. Ingen lesing eller skriving er tillatt etter frakobling. Etter at arrangementet avsluttes, kaller ikke lyttetråden det lenger, men tømmer tråden og avslutter forbindelsen.
Hvis kommandoen er "ZipCode", blir parameteren etter kommandoen trukket ut og tabellen skannet for tilstedeværelsen av byen og staten. Byen og staten sendes deretter til klienten, eller en tom streng sendes hvis det ikke er samsvar.
Deretter avsluttes metoden. Serveren vil gjenoppta hendelsen igjen så snart en ny kommando kommer, slik at klienten kan sende flere kommandoer.
Klientkildekode

enhet ClientMain;

grensesnitt

bruker

Windows, meldinger, SysUtils, klasser, grafikk, kontroller, skjemaer, dialogbokser,

StdCtrls, ExtCtrls, IdAntiFreezeBase,

IdAntiFreeze, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient;

type

TformMain = klasse(TForm)

Klient: TIDTCPClient;

IdAntiFreeze1: TIdAntiFreeze;

Panel1: TPanel;

Panel2: TPanel;

MemoInput: TMemo;

LboxResultater: TListBox;

Panel3: TPanel;

Knapp1: TBknapp;

Knapp 2: TB-knapp;

Etikett1: TLabel;

prosedyre Button2Click(Sender: TObject );

prosedyre Button1Click(Sender: TObject );

privat

offentlig

slutt ;

FormMain: TformMain;

gjennomføring

(R*.DFM)

prosedyre TformMain.Button2Click (Sender: TObject );

begynne

MemoInput.Clear ;

LboxResults.Clear ;

slutt ;

prosedyre TformMain.Button1Click (Sender: TObject );

I: heltall ;

S: streng ;

begynne

ButnLookup.Enabled := true ; prøve

LboxResults.Clear ;

med klienten begynner

Koble; prøve

LboxResults.Items.Add(ReadLn);

for i:= 0 til memoInput.Lines .Count - 1 begynner

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

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

S:= ReadLn ;

hvis s = "" så begynn

S:= "-- Ingen oppføring funnet for dette postnummeret.";

slutt ;

LboxResults.Items.Add(s);

LboxResults.Items.Add("");

slutt ;

WriteLn("Avslutt");

til slutt Koble fra; slutt ;

slutt ;

endelig butnLookup.Enabled := true ; slutt ;

slutt ;

slutt.

De eneste delene som er spesifikke for klientkomponenten er Button1Click-metoden.
Klientkomponenten er av typen TIdTCPClient og plassert på skjemaet. Følgende egenskaper er endret: ·Vert = 127.0.0.1 - Serveren er plassert på samme maskin som klienten. ·Port = 6000 - Serverport
Button1Click-metoden er knyttet til OnClick-hendelsen til Button1-komponenten. Når knappen klikkes, kalles denne metoden. Indy-delen av denne metoden kan reduseres til følgende: 1.Koble til serveren (Koble til;) 1.Les hilsenen fra serveren. 1. For hver linje som legges inn av brukeren i TMemo: 1. Sende en forespørsel til serveren (WriteLn("ZipCode " + memoInput.Lines[i]);) 1. Lese et svar fra serveren (s:= ReadLn; ) 1. Sende Avslutt-kommandoen (WriteLn("Avslutt");) 1.Koble fra (Koble fra;)
Testing
Dette eksemplet har blitt testet og fungerer med TCP/IP installert. Du kan endre den til å fungere over et nettverk fra én datamaskin til en annen. Ved å starte serveren på en annen datamaskin og endre navnet eller IP-en til serveren på klienten.
For å teste prosjekter, kompiler og kjør serveren. Deretter kompiler og kjør klienten. Skriv inn postnummeret ditt i notatfeltet og trykk på oppslagstasten.
Feilsøking
Tekstprotokoller er veldig enkle å feilsøke fordi de kan testes ved hjelp av Telnet. For å gjøre dette er det nok å kjenne serverporten. ZIP Code Lookup Server lytter på port 6000.
Start ZIP Code Lookup Server igjen. Åpne deretter en konsoll (f.eks. et Dos-vindu). Skriv nå inn:
telnet 127.0.0.1 6000
Du er nå koblet til serveren. Noen servere sender også en velkomstmelding. Noen gjør ikke det. Du vil ikke se linjene du legger inn. De fleste servere ekko ikke for å spare trafikk. Du kan imidlertid endre telnet-innstillingene ved å sette alternativet "Echo On". Dette gjøres forskjellig i forskjellige telnet-klienter, og noen har ikke denne funksjonen i det hele tatt. Skriv nå inn:
postnummer 37642
Du vil se serversvaret:
CHURCH HILL, TN
For å koble fra serveren, skriv inn:
slutte
Eksempel 2 - databasetilgang
Dette eksemplet emulerer en server som må utføre andre blokkeringsoppgaver enn socket calls. Mange servere er tvunget til å jobbe under slike forhold. Servere som trenger tilgang til databasen, kaller eksterne prosedyrer eller beregninger kan ofte ikke avbryte disse samtalene, fordi de er eksterne samtaler eller på grunn av kompleksiteten i dette. Tilgang til databasen kan ikke deles i små biter og utvikleren må vente på at operasjonen med databasen skal fullføres. Dette er en funksjon ikke bare ved databaseanrop, men også for andre operasjoner som komprimering, beregninger og annen behandling av samme type.
For demonstrasjonsformål, la oss forestille oss at serveren foretar et databasekall som tar 5 sekunder å fullføre. For å forenkle, la oss gjøre dette ganske enkelt med en pause, bruk Sleep(5000)-funksjonen for dette, i stedet for å faktisk ringe.
Dette eksemplet krever også mindre detaljer enn det forrige eksemplet fordi mange av konseptene ennå ikke er klare.
Kilde

hovedenhet;

grensesnitt

bruker

Windows, meldinger, SysUtils, klasser, grafikk, kontroller, skjemaer, dialogbokser,

IdBaseComponent, IdComponent, IdTCPServer;

type

TformMain = klasse(TForm)

IdTCPServer1: TIdTCPServer;

prosedyre IdTCPServer1Execute(ATråd: TIdPeerThread) ;

privat

offentlig

slutt ;

FormMain: TformMain;

gjennomføring

(R*.DFM)

prosedyre TformMain.IdTCPServer1Execute (AThread: TIdPeerThread) ;

I: heltall ;

begynne

med AThread.Connection begynner

WriteLn("Hei. DB-server klar.");

I:= StrToIntDef(ReadLn, 0);

// Sleep erstattes av en lang DB eller annen samtale

Søvn(5000);

WriteLn(IntToStr(i * 7));

slutt ;

slutt ;

slutt.

Fordi Execute-hendelsen oppstår i sammenheng med en tråd, kan behandlingskoden være av hvilken som helst lengde. Hver klient har sin egen tråd og blokkerer ikke andre klienter.
Testing
For å teste DB-serveren, kompiler og kjør den. Koble til den ved hjelp av Telnet til port 6001. Serveren vil svare med en velkomstmelding. Skriv inn nummeret. Serveren vil "behandle" forespørselen din og svare innen 5 sekunder.

UDP-protokollen er ganske god for å overføre tekstmeldinger, det vil si at du kan organisere lokale chatter og lignende. Jeg bestemte meg for å gi et eksempel på det enkleste arbeidet med UDP i Delphi.

Trinn-for-steg instruksjon:

Jeg ga et eksempel, men tilgi meg, jeg skrev ikke ned hver linje, fordi... Jeg ser ikke noe komplisert, og alle kan finne ut av det.

Faktisk, hvis noe er uklart, kan du stille meg et spørsmål. Og her er den faktiske koden:

bruker
Windows, meldinger, SysUtils, varianter, klasser, grafikk, kontroller, skjemaer,
Dialoger, StdCtrls, IdUDPServer, IdBaseComponent, IdComponent, IdUDPBase,
IdUDPClient, IdSocketHandle;

type
TForm1 = klasse(TForm)
IdUDPClient1: TIdUDPClient;
IdUDPServer1: TIdUDPServer;
Knapp1: TBknapp;
Etikett1: TLabel;
prosedyre FormCreate(Sender: TObject);
prosedyre FormClose(Avsender: TObject; var Handling: TCloseAction);
prosedyre Button1Click(Sender: TObject);
prosedyre IdUDPServer1UDPRead(ATråd: TIdUDPListenerThread; AData: TBytes;
ABinding: TIdSocketHandle);
privat
(Private erklæringer)
offentlig
(Offentlige erklæringer)
slutt;

var
Form1: TForm1;

($R *.dfm)
[b]//Prosedyre for å sende en melding
prosedyre TForm1.Button1Click(Sender: TObject);
begynne
prøve
IdUDPClient1.Active:= Sant;
IdUDPClient1.Host:= "localhost";
IdUDPClient1.Connect;
hvis IdUDPClient1.Connected da
begynne
IdUDPClient1.Send(TimeToStr(Time));
Label1.Caption:= "ok";
slutt;
IdUDPClient1.Active:= False;
Pip;Pip;Pip;
unntatt
MessageDlg("Noe gikk galt =(", mtError, , 0);
slutt;
slutt;
[b]
//På av. UDP-server ved oppstart og lukking av skjemaet
prosedyre TForm1.FormClose(Sender: TObject; var Handling: TCloseAction);
begynne
IdUDPServer1.Active:= False;
slutt;

prosedyre TForm1.FormCreate(Sender: TObject);
begynne
IdUDPServer1.Active:= Sant;
slutt;

[b]// Serverreaksjonsprosedyre ved mottak av data
prosedyre TForm1.IdUDPServer1UDPRead(ATråd: TIdUDPListenerThread;
AData: TBytes; ABinding: TIdSocketHandle);
Var
i: Heltall;
s:streng;
begynne
s:= "";
prøve
i:= 0;
mens (AData[i] 0) gjør
begynne
s:= s + chr(AData[i]);
i:= i + 1;
slutt;
endelig
Label1.Caption:= s;
slutt;
slutt;