Uvod v Indy. Razvoj aplikacij odjemalec-strežnik z uporabo Indyja v Delphiju

Komponente Indy, uporabljene v Delphiju 6.

Poleg osnovnih internetnih storitev in protokolov obstaja širok nabor dodatnih storitev, katerih zmogljivosti internetni razvijalci pogosto uporabljajo. Poleg tega možnost prikaza informacij z uporabo brskalnika ni vedno sprejemljiva rešitev za internetne aplikacije. V tem primeru je smiselno uporabiti internetno infrastrukturo za izmenjavo podatkov in zagotoviti prikaz informacij prek kompleksnejših odjemalskih aplikacij, razvitih na primer v Delphiju.

Recimo, da morate implementirati specializirano strežniško logiko, ki ni vključena v standardne spletne strežnike. Za rešitev tega razreda problemov Delphi vključuje knjižnico Internet Direct (Indy) podjetja Nevrona Designs (http://www.nevrona.com/Indy/). Ta knjižnica, razvita posebej za Borland Delphi, ima že osem različic, od katerih je zadnja vključena v nova različica Delphi. Nabor komponent je razdeljen v tri skupine: odjemalec (Indy Client), strežnik (Indy Servers) in pomožni (Indy Misc).

Stranke Indy in Indy strežnik s

Večina komponent Indy Client in Indy Servers je parov, ki ustrezajo odjemalskim in strežniškim delom protokolov in storitev (z izjemo nekaterih, predvsem strežniških komponent, kot sta TunnelMaster in TunnelSlave), in omogočajo uporabo protokolov, kot je TCP/IP , UDP, NNTP, SMTP, FTP, HTTP, kot tudi storitve ECHO, FINGER, WHOIS itd.

Komponente odjemalca Indy so napisane z uporabo vtičnic. Vtičnica na strani odjemalca zahteva povezavo s strežnikom. Če je povezava vzpostavljena, lahko odjemalec in strežnik začneta izmenjevati sporočila. Ta sporočila so drugačne narave, vendar običajno izmenjava poteka z uporabo določenega protokola (na primer HTTP)

TIdTCPClient in TIdTCPServer

Te komponente se uporabljajo za podporo enega od glavnih omrežnih protokolov - TCP (Transmission Control Protocol), in so tudi osnovni razredi za komponente TIdSMTP in TIdFTP. Razred TIdTCPServer ima lastnost ThreadMgr, ki je privzeto nastavljena na nič. Če je ThreadMgr enak nič, ko je TIdTCPServer omogočen, bo razred TIdThreadMgrDeafault ustvarjen implicitno. V nasprotnem primeru se uporablja nameščeni upravljalnik procesov.

TIdUDPClient in TIdUDPServer

Te komponente se uporabljajo za podporo omrežni protokol UDP (User Datagram Protocol) in so tudi osnovni razredi za številne druge komponente Indy.

TIdChargenServer

Komponenta se uporablja za ustvarjanje naključnih simbolov, običajno za namene testiranja.

TIdDayTime in TIdDayTimeServer

Komponente se uporabljajo za zagotavljanje časovne storitve. Odjemalec zahteva, strežnik pa sporoči trenutni datum in uro.

Reševalec TIdDNSR

To je odjemalska komponenta, ki služi zahtevam strežnika DNS (Domain Name Service). Poizvedbe strežnika DNS so zasnovane tako, da zamenjajo ime računalnika z njegovim naslovom IP. TIdDNSResolver je potomec razreda TIdUDPClient.

TIdDICTServer

Strežniška komponenta, ki podpira Dictionary Server Protocol (DICT), slovar na strežniški strani, ki temelji na protokolu TCP, ki odjemalcu omogoča dostop do slovarja naravnega jezika.

TIdDISCARDServer

Komponenta strežnika, ki podpira strežnik zapisov. Posnetke je mogoče uporabiti kot orodje za odpravljanje napak in merjenje. Evidenčna služba morebitne podatke enostavno preda tistemu, ki jih je pripravljen prejeti.

TI dEcho in TI dECHOServer

Komponente so zasnovane za zagotavljanje odzivne storitve, ki se običajno uporablja za preverjanje zdravja omrežja. Odjemalec pošlje besedilno sporočilo strežniku, strežnik vrne sporočilo odjemalcu. Če je sporočilo popačeno, omrežje ne deluje pravilno.

TIdFinger in TIdFingerServer

Komponente so zasnovane tako, da zagotavljajo protokol, ki uporabniku omogoča poizvedovanje po podatkih o prisotnosti drugih uporabnikov v sistemu. Nekateri strežniki obravnavajo takšne zahteve strank. Uporaba tega para komponent vam bo omogočila servisiranje zahtev odjemalcev, ki določajo prisotnost drugih uporabnikov v sistemu.

Komponenta vključuje popolno podporo za protokol za prenos datotek - FTP (File Transfer Protocol). Podprt je pasivni in aktivni prenos podatkov, pa tudi operacije, kot sta GET in PUT, brisanje imenikov, pridobivanje kvot, velikosti datotek in imenikov. TI dFTP za delovanje uporablja razred TIdSimpleServer. Ko poteka prenos datoteke FTP, se odpre sekundarna povezava TCP za prenos podatkov in se zapre, ko so podatki preneseni. Ta povezava se imenuje "podatkovna povezava", edinstvena za vsako datoteko, ki se prenaša.

TIdGopher in TIdGopherServer

Te komponente so zasnovane za zagotavljanje omrežnega protokola, ki je bil nadomeščen v Zadnje čase iz WWW (Svet Wide Web) protokol HTTP. Strežnik, ki izvaja ta protokol, zagotavlja hierarhično porazdeljen sistem za podporo pretoka dokumentov. Primer uporabe tega para komponent, ki se nahaja v imeniku demosindyGopherClient in demosindy GopherServer, prikazuje, kako se ta protokol lahko uporablja za zagotavljanje lokalno omrežje informacije o datotekah v vašem računalniku, vključno z zaprtimi.

TIdHostNameServer

Komponenta strežnika, zasnovana za posredovanje imena lokalnega strežnika odjemalcem.

TIdHTTP in TIdHTTPServer

Komponente se uporabljajo za zagotavljanje omrežnega protokola HTTP (podprti sta različici 1.0 in 1.1, vključno z operacijami GET, POST in HEAD). Poleg tega je zagotovljena podpora za avtentikacijo in uporabo proxy strežnikov. Strežniška komponenta se uporablja za zagotavljanje storitev drugemu spletnemu strežniku, ki podpira dani protokol. TIdHTTPServer olajša izvajanje funkcij, kot so piškotki, upravljanje stanja itd.

TIdIcmpClient

Komponenta odjemalca, zasnovana za zagotavljanje internetnega protokola za nadzorna sporočila (ICMP), ki se uporablja za izvajanje operacij ping in sledenje omrežju.

Odjemalska komponenta, zasnovana za zagotavljanje poštnega protokola (POP), vključno s podporo za kodiranje in dekodiranje MIME ter prenos večbajtnih znakov.

TIdIMAP4Server

Komponenta strežnika, zasnovana za podporo operacij IMAP (Internet Message Access Protocol) na strežniku. Protokol omogoča iskanje sporočil E-naslov na strežniku. Razlika med protokoloma IMAP in POP je v tem, da protokol POP zahteva dodatni pomnilnik za shranjevanje podatkov, protokol IMAP pa dostopa do strežnika namesto odjemalskega računalnika. IMAP4 je bil ustvarjen, da bi nadomestil POP3, vendar POP3 še danes ostaja pogosto uporabljen standard.

TIdIRCServer

Komponenta strežnika, zasnovana za podporo najpogosteje uporabljenih operacij storitev na internetu, običajno imenovanih klepet. Komponenta zagotavlja osnovno gradniki za strežnik IRC (Internet Relay Chat).

TIdMappedPortTCP

Komponenta strežnika, zasnovana za ustvarjanje preslikanih vrat, ki se pogosto uporabljajo v proxy strežnikih. Metode te komponente vam omogočajo, da ena vrata preslikate v druga. Na primer, vrata 80 bi lahko preslikali v vrata 3000 in vse zahteve do prvih vrat (vrata 80) bi bile posredovane drugim vratom (vrata 3000).

TIdNNTP in TIdNNTPServer

Te komponente so potrebne za podporo protokola Network News Transfer Protocol (NNTP), ki se uporablja v novičarskih storitvah. Odjemalska komponenta vključuje podporo za kodiranje in dekodiranje MIME ter podporo za večbajtne znake in alternativna kodiranja. Komponenta strežnika vam omogoča ustvarjanje strežnikov novic. Pomembno je omeniti, da TIdNNTPServer ni strežnik novic s polnimi funkcijami, ampak komponenta, ki zagotavlja osnovno funkcionalnost za tak strežnik.

TIdQOTD in TIdQOTDServer

Komponente se uporabljajo za zagotavljanje storitve Citat dneva. Odjemalska komponenta se poveže s primerkom strežniške komponente, da pridobi dnevno ponudbo. Vsak primerek strežnika vsebuje edinstveno bazo podatkov o citatih.

Odjemalska komponenta, zasnovana za uporabo v aplikacijah SMTP (Simple Mail Transfer Protocol), ki zagotavlja podporo za preverjanje pristnosti, kodiranje in dekodiranje MIME ter podporo za večbajtne znake.

Odjemalska komponenta, zasnovana za zagotavljanje SNTP (Simple Network Time Protocol) – časovne storitve. Uporablja se lahko za povezavo s katero koli časovno storitvijo za določitev trenutnega datuma in ure.

TIdSimpleServer

Komponenta strežnika, ki zagotavlja lahek strežnik TCP. Omogoča vam organiziranje povezave od točke do točke. Uporablja se za ustvarjanje strežnikov z enim uporabnikom, kar pomeni, da lahko služi samo eni povezavi hkrati. Za razliko od komponente TIdTCPServer ne ustvarja sekundarnih procesov, ko čaka na zahteve strank in obdeluje te zahteve. Z drugimi besedami, če strežnik streže zahtevo od odjemalca in v tem času drug odjemalec kontaktira z njim za povezavo, potem bo blokiran do konca obdelave prve zahteve.

TIdTelnet in TIdTelnetServer

Komponenta odjemalca se uporablja za organiziranje oddaljenih sej na drugem računalniku, vključno s pogajanji konzole in preverjanjem pristnosti. Komunikacijski protokol predvideva prisotnost osebe, ki interaktivno komunicira s strežnikom. Komponenta odjemalca nima podpore za zaslon ali emulacije terminala, ampak preprosto zagotavlja povezavo s strežniškim delom. Običajno se strežniški protokol TIdTelnetServer uporablja za organiziranje oddaljenih baz podatkov z besedilnim vmesnikom za interaktivno interakcijo s strankami.

TIdTime in TIdTimeServer

Odjemalska komponenta je alternativa komponenti TIdSNTP za določanje časa. Pomembno je omeniti, da sta formata obeh protokolov različna. TIdTime temelji na formatu RFC 868 (vrne čas v internem standardu OS UNIX in izvede vse potrebne pretvorbe). Komponenta strežnika je po delovanju podobna strežniku DayTime. Lahko se uporablja za implementacijo časovne storitve lokalni računalnik. Dodatna koda ni potrebna, samo ustvarite primerek TIdTimeServer, ki bo vrnil čas notranje ure strežniškega računalnika.

TIdTrivialFTP in TIdTrivialFTPServer

Te komponente so potrebne za organizacijo preprostega protokola za prenos datotek. Odjemalska komponenta tega protokola se uporablja za povezavo s primerkom ustrezne strežniške komponente. Protokol je namenjen zasebnim, lahkim, lokalnim primerom prenosa datotek, na primer v lokalnih omrežjih ali za nalaganje (nalaganje) usmerjevalnih tabel v usmerjevalnike. Zaradi oslabljenih lastnosti tega protokola njegova uporaba ni priporočljiva pri uporabi algoritmov za preverjanje pristnosti ali drugih varnostnih mehanizmov. Glavni namen tega protokola je prenos datotek na strojno napravo z namenom njenega spreminjanja.

TIdTunnelMaster in TIdTunnelSlave

Komponente strežniškega tunela se uporabljajo v strežnikih proxy za organiziranje več logičnih povezav prek enega fizičnega (tunela). Te razrede je mogoče uporabiti za različne namene, na primer za organizacijo skrivne povezave prek neskrivnih kanalov.

TIdWhois in TIdWhoIsServer

Ta odjemalska komponenta se poveže s katerim koli standardnim strežnikom Whois, kar vam omogoča pridobivanje informacij o domenah. Komponenta strežnika zagotavlja osnovno funkcionalnost strežnika NIC.

Indy Razno

Stran palete Indy Miscellaneous Components vključuje BASE64, UUE, Quoted Printable in druge običajne formate elektronske pošte, kodirnike (MD2, MD4 in MD5) za kriptografske standarde, ki se uporabljajo za shranjevanje gesel in elektronski podpisi v ireverzibilni (težko dešifrirani) obliki, pa tudi številne druge uporabne komponente in pripomočke, ki se pogosto uporabljajo pri razvoju internetnih aplikacij.

TIdAntiFreeze

Zaradi algoritmov komponent Indy, ki temeljijo na blokih, se pogosto zdi, da je aplikacija obstala, medtem ko povezava deluje. Če želite odpraviti uporabo sekundarnih procesov (niti) pri organiziranju komunikacij, da preprečite zamrznitev aplikacije, je dovolj, da navedeno komponento postavite na obrazec.

Komponenta deluje tako, da razčlenjuje zahteve iz sklada protokolov TCP/IP in pošilja sporočila aplikaciji med zakasnitvijo, ko so zunanje povezave blokirane, kar ustvarja iluzijo izvajanja kode. Ker komponenta vpliva na blokirane povezave samo za glavni proces, uporaba TIdAntiFreeze v sekundarnih procesih aplikacije ni potrebna. Ne pozabite, da komponenta TIdAntiFreeze upočasni povezave, ker se glavni proces občasno prekine zaradi obdelave sporočil. Iz tega sledi, da je treba paziti, da aplikacija, ki se razvija, ne porabi preveč časa za obdelavo sporočil, vključno z OnClick, OnPaint, OnResize itd. Do neke mere je to mogoče nadzorovati z lastnostmi razreda TIdAntiFreeze. Uporaba te komponente ni obvezna, vendar vam omogoča, da rešite problem sinhronizacije povezav z vizualnim vmesnikom aplikacije.

TIdDateTimeStamp

Razred za izvajanje matematike datuma in časa v zvezi z dejstvom, da internetni protokoli uporabljajo različne oblike zapisa datuma in časa; poleg tega se lahko odjemalci in strežniki nahajajo v različnih časovnih pasovih.

TIdIPWatch

Je komponenta, ki temelji na časovniku in nenehno spremlja spremembe naslova IP računalnika. Dogodki komponent se zgodijo, ko je zaznana sprememba. Ta komponenta se običajno uporablja za ugotavljanje, ali je računalnik povezan z internetom ali katerim koli drugim omrežjem. Do spremembe naslova IP v tej situaciji lahko pride zaradi naslova IP, ki ga dodeli strežnik DHCP (Dynamic Host Configuration Protocol) pri povezovanju z novim omrežjem.

TIdLogDebug

Namen te komponente je prestreči dogodke katere koli odjemalske ali strežniške komponente in vnesti zapis dogodka določeno datoteko. Ta komponenta je zelo uporabna za odpravljanje napak komponent Indy.

TIdMessage

Komponenta se uporablja v kombinaciji z drugimi komponentami za pravilno dešifriranje ali kodiranje sporočil. To so lahko komponente POP, SMTP in NNTP. Razred podpira šifriranje in dešifriranje MIME, večbajtne znake in kodiranje ISO.

TidNetworkCalculator

Ena redkih komponent Indy, ki jih je mogoče uporabiti pri gradnji aplikacij. Omrežni kalkulator se lahko uporablja za izračune naslovov IP, vključno z omrežnimi maskami, podomrežji, omrežnimi razredi itd.

TIdThreadMgrDefault

Komponenta privzeto zagotavlja nadzor nad sekundarnimi procesi. Ustvari se, ko katera koli komponenta Indy, ki podpira upravljanje procesov, nima definiranega primerka razreda TIdThreadManager. Komponenta ponuja le osnovne zmožnosti za upravljanje sekundarnih procesov: ustvarjanje in uničenje le-teh na zahtevo.

TIdThreadMgrPool

Naprednejša komponenta za upravljanje procesov kot TIdThreadMgrDefault, ker združuje procese, namesto da jih ustvarja ali uničuje na zahtevo.

TIdVCard

VCard je elektronski ekvivalent vizitke in lahko vsebuje osebne in grafične podatke lastnika.

TIdIMFDekoder

Zasnovan za dekodiranje internetnih sporočil. Je potomec razreda TIdCoder, tako kot vse druge komponente kodirnika. Razred TIdCoder dekodira v skladu s standardom formata besedilnih sporočil ARPA RFS-822, predlaganim avgusta 1982, in standardom za sporočanje USENET RFC 1036, predlaganim decembra 1987.

Komponenta razširja razred TIdCoder, da omogoči zaznavanje formata RFS-822 s kontekstom glave, zagotavlja način dešifriranja ob prejemu ter šifriranje in dešifriranje MIME. Komponenta TIdIMFDecoder se uporablja v razredu TIdMessageClient za dekodiranje prejetih in poslanih sporočil.

TIdQuotedPrintableEncoder

QuotedPrintableEncoder vam omogoča dešifriranje besedila v določenem formatu. Lahko služi kot samostojna komponenta z določeno vrsto kodiranja, ki omogoča prenos sporočil, ki vsebujejo novo vrsto kodiranja.

TIdBase64Encoder

Implementira drug šifrirni algoritem, ki omogoča prenos nenatisljivih znakov.

TIdUUEncoder

Implementira enega prvih šifrirnih algoritmov, UU kodiranje. Včasih se uporablja pri pošiljanju člankov novičarski službi.

TIdXXEncoder

Ta metoda šifriranja verjetno ne bo nikoli uporabljena. V bistvu je to isto kodiranje UU, vendar z drugačno tabelo šifriranja.

TIdCoderMD2

Komponente z različnimi vrstami šifrirnega algoritma MD (Message Digest). Vsi temeljijo na naključnem vrstnem redu, so enosmerni in nimajo algoritmov za dešifriranje.

Komponente protokolarnih odjemalcev in strežnikov se lahko uporabljajo za razvoj strežniških in odjemalskih internetnih aplikacij, skupaj ali namesto osnovnih (ClientSocket, ServerSocket) in drugih komponent iz interneta in palete Fastnet. Komponente Indy ne uporabljajo arhitekture WebBroker, saj implementirajo nizkonivojsko podporo za internetne protokole in storitve neposredno v svoji izvorni kodi (izvorne kode so vključene).

TIdConnectionInterceptOpenSSL in TIdServerInterceptOpenSSL

Protokol SSL – Secure Sockets Layer, ki zagotavlja tajnost in zanesljivost komunikacije med dvema aplikacijama, ima dva sloja. Na nizki ravni večslojnega transportnega protokola (kot je TCP) je SSL snemalni protokol in se uporablja za enkapsulacijo različnih protokolov višje ravni. Prednost SSL je v tem, da je neodvisen aplikacijski protokol, vendar je poleg SSL mogoče uporabiti protokol višje ravni.

SSL zagotavlja komunikacijsko varnost, ki ima tri glavne funkcije: zagotavljanje zaupne povezave; šifriranje z javni ključ(uporablja se za potrditev pristnosti naslovnika); podpora za zanesljivost prenosa podatkov.

  • Za šifriranje podatkov se uporablja simetrična kriptografija (npr. DES, RC4 itd.).
  • Digitalni podpis se zagotavlja z uporabo asimetričnega šifriranja z javnim ključem (na primer RSA, DSS itd.).
  • Zanesljivost komunikacije, prenos sporočila vključuje preverjanje celovitosti sporočila s pomočjo popravnih kod MAC, varnih zgoščevalnih funkcij (npr. SHA, MD5 itd.) z uporabo izračunov MAC.

V kombinaciji s HTTP in preverjanjem pristnosti strežnika zagotavlja SSL potrebne funkciješifriranje in nadalje vzdržuje vzpostavljeno povezavo, dvojno preverjanje pristnosti spletnega strežnika itd. Pomembno je razumeti, da SSL ščiti samo komunikacijo med prenosom podatkov in ne nadomešča drugih varnostnih mehanizmov.

Komponenti TIdConnectionInterceptOpenSSL in TIdServerInterceptOpenSSL zagotavljata tako povezave na strani odjemalca kot na strani strežnika z uporabo protokola SSL. Upoštevati je treba, da sta komponenti TIdConnectionInterceptOpenSSL in TIdServerInterceptOpenSSL na voljo samo v Delphiju 6 in ne v Kylixu. To je posledica zapletenosti protokola, ki v primeru izvedbe Windows temelji na funkcijah operacijskega sistema.

Primere uporabe komponent Indy lahko najdete v imenikih /Delphi6/Demos/Indy. Skupaj knjižnica Indy v različici 8.0 vsebuje 69 komponent. Navedeno je, da bo navedena knjižnica v različici 9.0 vsebovala 86 komponent. Vse komponente so poenotene in vključene tako v Delphi 6 kot v Kylix, kar omogoča njihovo uporabo za razvoj večplatformskih aplikacij. Vse komponente Indy podpirajo večnitnost.

Komponente Indy izvajajo skoraj vse funkcije, ki jih najdemo v komponentah Internet in Fastnet, kot je jasno prikazano v tabeli.

Hitre komponente Indy komponente Namen komponent
1 TserverSocket, TClientSocket TIdTCPserverSocket, TIdTCPClientSocket Interakcija med dvema računalnikoma (odjemalec in strežnik) po protokolu TCP/IP
2 TNMDayTime TIdDayTime, TIdDayTimeServer Poizvedite strežnik za trenutni čas
3 TNMEcho TIdEcho, TIdEchoServer Uporablja se za komunikacijo z odzivnim strežnikom
4 TNMFinger TIdFinger, TIdFingerServer Uporablja se za pridobivanje informacij o uporabniku iz internetnega iskalnega strežnika
5 TNMFTP TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer Zagotovite prenos datotek s protokolom FTP
6 TNMHTTP TIdHTTP, TIdHTTPServer Za izmenjavo podatkov uporabite protokol HTTP
7 TNMMsgServ, TNMMsg Uporablja se za prenos preprostih tekstovna sporočila od odjemalca do strežnika
8 TNMNNTP TIdNNTP, TIdNNTPServer Podpira izmenjavo podatkov s strežnikom novic
9 TNMPOP3 TIdPOP3 Uporablja se za prejemanje e-pošte s poštnega strežnika s protokolom POP3
10 TNMSMTP TIdSMTP Uporablja se za pošiljanje e-pošte prek poštni strežnik Internet
11 TNMStrm, TNMStrmServ Prenaša binarne podatke, zapisane v tok z uporabo protokola TCP/IP
12 TNMUDP TIdUDP, TIdUDPServer Prenesite podatke s protokolom UDP
13 TpowerSock, TNMGeneralServer Komponentno inkapsulirani razredi, ki so osnova za pisanje lastnih odjemalcev (Powersock) in strežnikov (NMGeneralServer)
14 TNMUUProcesor TIdUUEncoder, TIdUUDecoder Izvedite ponovno kodiranje binarne datoteke v format MIME ali UUENCODE
15 TNMURL Pretvori nize v obliko HTML in izvede obratno pretvorbo

Izjema so razredi, kot so TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, ki izvajajo zastarele protokole ali imajo funkcionalnost implementirano v veliki skupini alternativnih razredov.

Za razliko od svojih predhodnikov – komponent interneta in Fastneta pa Indy vsebuje bogatejše strežniške komponente in komponente za transkodiranje in šifriranje podatkov ter podporo za avtentikacijo (paleta Indy Misc). Kot je razvidno iz zgornje tabele, glavne protokole in storitve zagotavljajo ne le odjemalske, ampak tudi strežniške komponente. To so časovne storitve, odzivne storitve, pridobivanje informacij o uporabnikih, pa tudi protokoli HTTP, NNTP, UDP in celo najpreprostejša različica FTP.

Nekaj ​​primerov uporabe komponent Indy

V komponentah Indy, ki jih vsebuje Delphi, je naslov IP definiran v lastnosti Host, običajno samo v odjemalskih aplikacijah. Komponente, ki gostujejo v strežniku, imajo metode, ki vam omogočajo, da začnete ali ustavite preverjanje ustreznih vrat – na primer, če spremenite lastnost Active komponente IdTCPServer, se zažene ali ustavi preverjanje ustreznih vrat. Ko je povezava med odjemalcem in strežnikom vzpostavljena, se lahko začne prenos podatkov.

Komponente Indy dajejo velik poudarek varnosti in zanesljivosti pri delu s podatki. Na primer, komponenta IdTCPClient ima metode Connect in Disconnect. Uporaba tehnike programiranja, kot je spodnja koda s strani odjemalca:

S TCPClient začnite Connect; poskusite lstMain.Items.Add(ReadLn); končno Odklopi; konec; konec;

in z uporabo lastnosti Connection, posredovane kot parameter primerku AThread razreda TIdPeerThread s strani strežnika:

Z AThread.Connection naredite začetek WriteLn("Pozdrav iz strežnika Basic Indy Server."); Odklopi; konec;

računate lahko bodisi na normalno izvedbo povezave bodisi na pravilno obravnavo napak.

Upoštevajte metodi ReadLn in WriteLn ustreznih razredov - podobni sta standardnim V/I stavkom Pascal. To je poklon tehniki programiranja UNIX, kjer se večina sistemskih operacij izvede z branjem in pisanjem v ustrezne datoteke.

Tako kot komponente Fastnet imajo razredi komponent Indy dogodke, ki jih je mogoče uporabiti za zagotavljanje upravljanja dogodkov. Na primer, lahko uredite, da se sporočilo prikaže na obrazcu, ko se povezujete z odjemalcem:

Procedure TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Serving client ]"; konec;

Indy ponuja komponente, ki izvajajo protokole z deli odjemalca in strežnika, ki so edinstveni za to knjižnico. Komponenti TIdGopherServer in TIdGopher, zahvaljujoč metodam GetExtendedMenu, GetFile, GetMenu, GetTextFile na strani odjemalca in ReturnGopherItem, SendDirectoryEntry na strani strežnika, pomagata pri ogledovanju datotek različne vrste, vključno s tistimi, ki so označeni kot skriti, kot tudi imeniki na oddaljeni računalnik(podobno kot naredi ukaz dir *.* v operacijski sistem MS-DOS).

Z uporabo komponent IdSMTP in IdMessage lahko preprosto ustvarite lastno spletno aplikacijo, ki lahko pošilja pošto po protokolu SMTP.

V tem primeru je za generiranje sporočila odgovoren razred IdMessage (ena od 23 komponent s strani Indy Misc), ki izhaja iz njegovega imena, IdSMTP pa za organizacijo povezave s poštnim strežnikom.

Tehnologija, uporabljena v Indyju, uporablja zaklepanje operacij branja in pisanja. Vsaka operacija Connect, uporabljena v Indyju, čaka na dokončanje povezave. Ko delate s komponentami odjemalca Indy, morate običajno storiti naslednje:

  • zahtevajte povezavo s strežnikom;
  • pošiljanje zahtev za branje in pisanje na strežnik (odvisno od vrste strežnika se korak izvede enkrat ali večkrat ponovi);
  • prekinite povezavo s strežnikom in prekinite povezavo.

Komponente Indy so zasnovane tako, da zagotavljajo izjemno visoko raven abstrakcije. Zapletenost in podrobnosti sklada TCP/IP so programerju skrite, tako da se lahko osredotoči na trenutno nalogo.

Naslednji majhen primer prikazuje tipično sejo gradnika odjemalca:

Z IndyClient začnite Host:= "zip.pbe.com"; // Gostitelj za klic Port:= 6000; // Vrata za klic strežnika na Connect; poskusi // Vaša koda gre tukaj končno Odklopi; konec; konec;

V primeru, tudi če povezava s strežnikom ni vzpostavljena, bo povezava elegantno prekinjena zaradi uporabe stavka try-finally.

Komponente strežnika Indy opisujejo različne modele strežnikov, ki jih je mogoče uporabiti glede na vaše potrebe in protokol, ki ga uporabljate.

TIdTCPServer je najpogosteje uporabljena strežniška komponenta, ki ustvari sekundarni proces, neodvisen od glavnega aplikacijskega procesa. Ustvarjeni proces čaka na dohodne zahteve od potencialne stranke. Individualni sekundarni proces se ustvari za vsako stranko, na zahtevo katere odgovarja. Dogodki, ki se zgodijo med procesom vzdrževanja, so povezani s kontekstom ustreznih procesov.

Z drugimi besedami, za vsako povezavo odjemalca razred TIdTCPServer uporabi edinstveno sekundarno nit tako, da pokliče obravnavo dogodkov OnExecute te niti. Formalni parameter metode OnExecute je sklic na primerek razreda Athread, ki ustreza ustvarjeni niti. Lastnost Connection tega razreda je sklic na razred TIdTCPConnection, katerega primerek je ustvarjen za obdelavo zahteve odjemalca. TIdTCPConnection podpira branje in pisanje prek povezave ter vzpostavljanje in prekinitev komunikacijske seje.

Protokol UDP deluje brez predhodne vzpostavitve povezave s strežnikom (vsak poslan paket je neodvisen nabor podatkov in ni del večje seje ali povezave). Medtem ko TIdTCPServer ustvari ločene niti za vsako povezavo, TIdUDPServer uporablja glavno nit ali eno sekundarno nit, ki obravnava vse zahteve protokola UDP. Ko je TIdUDPServer aktiven, se ustvari nit za poslušanje dohodnih paketov UDP. Za vsak prejeti paket se sproži dogodek OnUDPRead v glavni niti ali v kontekstu poslušajoče niti, odvisno od vrednosti lastnosti ThreadedEvent. Ko je ThreadedEvent ovrednoten na False, se dogodek zgodi v glavni niti, sicer pa v poslušajoči niti. Medtem ko se dogodek obdeluje, so druge operacije strežnika blokirane. Zato je pomembno zagotoviti, da se postopki OnUDPRead izvajajo čim hitreje.

Če morate ustvariti novo odjemalsko aplikacijo za obstoječi strežnik z uporabo obstoječega protokola, je vaša naloga izključno razvoj in odpravljanje napak v odjemalski aplikaciji. Ko pa moramo razvijati tako odjemalske kot strežniške aplikacije z uporabo obstoječega ali novega protokola, se soočimo s klasičnim problemom "kokoš in jajce". Kje začeti programirati - pri odjemalcu ali pri strežniku?

Očitno je treba na koncu ustvariti tako odjemalca kot strežnik. Za številne aplikacije, zlasti tiste, ki uporabljajo besedilni protokol (kot je HTTP), je lažje začeti graditi aplikacijo z načrtovanjem strežnika. In za odpravljanje napak obstaja priročen odjemalec, ki že obstaja. To je konzolna aplikacija Telnet, ki je na voljo v sistemih Windows in UNIX.

Če vtipkate konzolo ukaz telnet 127.0.0.1 80 z naslovom IP lokalnega računalnika in številko vrat 80, ki jih privzeto uporabljajo spletni strežniki, potem se bo aplikacija odzvala z besedilom, prikazanim na sl. 6, v primeru operacijskega sistema Windows 2000 in IIS 5.0.

Če želite ustvariti najpreprostejši strežnik z uporabo komponent Indy, potrebujete:

Če morate zasnovati strežnik, ki ne bo le pravilno obvestil svojih odjemalcev, ko se povezava prekine, temveč jim bo zagotovil tudi informacije o napakah, ki so se zgodile, uporabite stavek poskusi razen namesto poskusi končno - na primer kot prikazano v naslednjem primeru:

Procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: niz; začnite z AThread.Connection do poskusite poskusite s:= ReadLn; // Izvedite nalogo strežnika tukaj // če ni sprožene nobene izjeme, // izpišite odgovor strežnika WriteLn(s); razen na e: Izjema do begin WriteLn(e.Message); end; //on end; //poskusite, razen končno Prekini povezavo; konec; konec;

Ta majhen primer prikazuje korake za ustvarjanje preprostega besedilnega strežnika, pa tudi, kako v njem odpraviti napake.

Zgoraj opisani strežnik je tipičen primer organizacije sodobnega porazdeljenega računalništva.

Značilnosti ustvarjanja večplastnih aplikacij

V zadnjem času se za zadovoljevanje zahtev strank vse pogosteje uporablja več strežnikov. Strežnik te vrste, ko prejme zahtevo odjemalca in jo delno pripravi za nadaljnjo obdelavo, vzpostavi stik z drugim strežnikom in mu pošlje preoblikovano zahtevo ali zahteve. Strežnik drugega nivoja lahko nato komunicira z drugimi strežniki. Tako lahko govorimo o večnivojski strežniški arhitekturi.

Nato bomo ustvarili strežnik za dostop do podatkov, katerega namen je vračanje podatkov iz baze podatkov. Vendar pa ta strežnik ne bere neposredno datotek baze podatkov ali piše vnje. Namesto tega komunicira s strežnikom baze podatkov in išče podatke, ki jih zahteva odjemalec.

Tako začnemo razvijati aplikacijo s trinivojsko arhitekturo. Če želite ustvariti strežnik baze podatkov z uporabo komponent Indy, potrebujete:

  1. Ustvarite nov projekt.
  2. Postavite na glavna oblika projektirajte primerek komponente TIdTCPServer iz palete Indy Servers.
  3. Nastavite lastnost DefaultPort instance razreda TIdTCPServer1 na 6001 (priporočljivo je dodeliti velike vrednosti, da se izognete podvajanju številk vrat v različnih aplikacijah) in nastavite lastnost Active na true.
  4. Projektu dodajte nov modul tako, da izberete Datoteka | Novo | Data Module in vanj postavite primerke komponent SQLConnection in SQLDataSet z zavihka dbExpress na paleti komponent.
  5. Nastavite lastnost ConnectionName razreda SQLConnection na IBLocal in LoginPrompt na False. Če niste konfigurirali IBLocal v zbirki podatkov employee.gdb, najprej dokončajte ta postopek.

Uvod v Indy

Uvod v Indy
Objavil Chad Z. Hower
Domača stran: http://www.atozedsoftware.com
Prevod: Anatolij Podgoretski
uvod
Ta članek sem napisal, ko trenutna verzija je bil Indy 8.0. Velik del tega članka je uporaben in zelo uporaben v prihodnjih različicah Indyja. Če vam je bil ta članek všeč in želite prebrati več poglobljenih člankov, si oglejte knjigo Indy in Depth.
Indy deluje v načinu blokiranja
Indy uporablja blokirne vtičnice. Način blokiranja je podoben načinu branja in pisanja datotek. Pri branju ali zapisovanju podatkov funkcija ne vrne nadzora, dokler operacija ni končana. Razlika od dela z datotekami je v tem, da lahko klic traja dlje, saj zahtevani podatki še ne obstajajo, odvisno od hitrosti, s katero deluje vaše omrežje ali modem.
Metoda se na primer preprosto pokliče in počaka, da se nadzor vrne klicni točki. Če je bil klic uspešen, bo metoda vrnila nadzor; če pride do napake, se sproži izjema.
Zaklepanje ni usodno
Zaradi načina blokiranja so nas nasprotniki velikokrat premagali, vendar način blokiranja ni hudič.
Težava se je pojavila po prenosu Winsocka v Windows. V Unixu je bila težava običajno rešena z razcepom (podobno večnitnosti, vendar z ločenimi procesi namesto niti). Odjemalci in demoni Unix so morali razcepiti procese, ki bi se morali izvajati, in uporabiti način blokiranja. Windows 3.x ni bilo mogoče paralelizirati in ni podpiral veliko niti. Uporaba vmesnika za blokiranje je zamrznila uporabniški vmesnik in povzročila neodzivnost programov. Zato so bili v WinSock dodani načini brez blokiranja, kar je sistemu Windows 3.x s svojimi omejitvami omogočilo uporabo Winsocka brez blokiranja glavne in edine niti programa. To je zahtevalo drugačno programiranje, Microsoft in drugi pa so strastno zaničevali načine blokiranja, da bi prikrili pomanjkljivosti sistema Windows 3.x.
Potem je prišel Win32, ki je lahko podpiral večnitnost. Toda v tem času so bili njihovi možgani že zmešani (to pomeni, da so razvijalci menili, da je blokiranje vtičnic hudičevo ustvarjanje) in že je bilo težko spremeniti, kar so storili. Zato se blatenje blokirnih režimov nadaljuje.
V resnici ima Unix samo blokirne vtičnice. Blokirne vtičnice imajo tudi svoje prednosti in so veliko boljše za večnitnost, varnost in druge vidike. Nekatere razširitve so bile dodane Unixu za vtičnice, ki ne blokirajo. Delujejo pa zelo drugače kot v sistemu Windows. Prav tako so nestandardni in niso zelo pogosti. Blokirne vtičnice v Unixu se uporabljajo v skoraj vseh primerih in se bodo še naprej uporabljale.
Prednosti načina blokiranja · Enostavnejše programiranje - Načine blokiranja je lažje programirati. Vsa uporabniška koda je lahko na enem mestu in se izvaja v naravnem, zaporednem vrstnem redu. ·Lažji prenos v Unix - Ker Unix uporablja blokirne vtičnice, je v tem primeru prenosljivo kodo lažje napisati. Indy to dejstvo uporabi za pisanje enotne kode. ·Priročneje je delati z nitmi - ker imajo blokirne vtičnice zaporedje, pridobljeno z dednostjo, jih je zelo enostavno uporabljati v nitih.
Slabosti načina blokiranja · Uporabniški vmesnik zamrzne v odjemalcih - klic vtičnice za blokiranje ne vrne nadzora, dokler ne dokonča svoje naloge. Ko je tak klic izveden v glavni niti aplikacije, aplikacija ne more obdelati uporabniških sporočil. To povzroči, da uporabniški vmesnik zamrzne, okna se ne osvežijo in nobeno drugo sporočilo ni obdelano, dokler se nadzor ne vrne iz vtičnice za blokiranje.
Komponenta TIdAntiFreeze
Indy ima posebno komponento, ki rešuje problem zmrzovanja Uporabniški vmesnik. Preprosto dodajte eno komponento TIdAntiFreeze kamor koli v svoji aplikaciji in lahko blokirate klice, ne da bi zamrznili uporabniški vmesnik.
TIdAntiFreeze deluje na notranjem časovniku zunaj sklada klicev in pokliče Application.ProcessMessages, ko poteče časovna omejitev. Zunanji klici v Indy še naprej blokirajo in zato delujejo popolnoma enako kot brez uporabe komponente TIdAntiFreeze. Uporaba TIdAntiFreeze vam omogoča, da izkoristite vse prednosti blokiranja vtičnic brez kakršnih koli pomanjkljivosti.
Kodne niti (Threading)
Pri blokirnih vtičnicah se skoraj vedno uporabljajo tokovi kode. Neblokirne vtičnice lahko uporabljajo tudi niti, vendar to zahteva nekaj dodatno obdelavo in njihove prednosti so v tem primeru izgubljene v primerjavi z blokirnimi vtičnicami.
Prednosti niti · Nastavitev prioritet - Prioritete posameznih niti je mogoče konfigurirati. To omogoča, da se posameznim nalogam dodeli več ali manj CPE časa. · Enkapsulacija - Vsaka povezava lahko vsebuje nekaj podobe vmesnika z drugo povezavo. · Varnost - Vsaka nit ima lahko različne varnostne atribute. · Več procesorjev - zagotavlja prednost pri sistemih z več procesorji. · Ni potrebe po serializaciji - zagotavlja popolno sočasnost. Brez velikega nizanja niti je treba vse zahteve obdelati v eni niti. Zato je treba vsako nalogo razdeliti na majhne dele, da lahko hitro deluje. Medtem ko en blok teče, so vsi drugi prisiljeni čakati, da se konča. Na koncu enega bloka se izvede naslednji in tako naprej. Z večnitnostjo je vsako opravilo mogoče programirati kot eno samo enoto, operacijski sistem pa čas porazdeli med vsa opravila.
Niti anket
Ustvarjanje in uničevanje niti zahteva veliko virov. To je še posebej težka naloga za strežnike, ki imajo kratkotrajne povezave. Vsak strežnik ustvari nit, jo kratek čas uporablja in nato uniči. Zaradi tega se niti zelo pogosto ustvarjajo in brišejo. Primer tega je spletni strežnik. Poslana je ena zahteva in vrnjen preprost odgovor. Pri uporabi brskalnika lahko med ogledom katerega koli spletnega mesta pride do na stotine povezav in prekinitev povezave.
Anketne niti lahko popravijo to situacijo. Namesto ustvarjanja in uničenja niti na zahtevo se niti izberejo s seznama neuporabljenih, a že ustvarjenih niti iz skupine. Ko nit ni več potrebna, se vrne v bazen, namesto da bi bila uničena. Niti v bazenu so označene kot neuporabljene in zato ne porabljajo časa procesorja. Za še večje izboljšave se lahko niti dinamično prilagajajo trenutnim potrebam sistema.
Indy podpira anketiranje niti. Področje niti v Indyju je dostopno prek komponente TIdThreadMgrPool.
Veliko niti
Močno obremenjen strežnik lahko zahteva na stotine ali celo tisoče niti. Obstaja splošno prepričanje, da lahko na stotine in tisoče niti uničijo vaš sistem. To je napačno prepričanje.
V večini strežnikov niti čakajo na podatke. Med čakanjem na klic za blokiranje je nit neaktivna. V strežniku s 500 niti jih je lahko hkrati aktivnih samo 50.
Število niti, ki se izvajajo v vašem sistemu, vas bo morda presenetilo. Z minimalnim številom delujočih strežnikov in določeno izvajanju aplikacij moj sistem ima ustvarjenih 333 niti, tudi s 333 niti je CPU obremenjen le 1%. Močno obremenjeno strežnik IIS(Microsoft Internet Information Server) lahko ustvari na stotine in tisoče niti.
Niti in globalni razdelki
Pri več nitih morate pri dostopu do njih zagotoviti celovitost podatkov. To je lahko težko za programerje, ki še niso delali z nitmi. Toda na splošno večini strežnikov ni treba uporabljati globalnih podatkov. Večina strežnikov izvaja izolirane funkcije. Vsaka nit opravlja svojo izolirano nalogo. Globalni odseki za branje/pisanje so značilnost številnih večnitnih aplikacij, vendar niso značilni za strežnike.
Metodologija Indy
Indy se razlikuje od drugih komponent Winsock, ki ste jih vajeni. Če ste delali z drugimi komponentami, potem najboljša rešitev bodo pozabili, kako delujejo. Številne druge komponente uporabljajo neblokirne (asinhrone) klice in delujejo asinhrono. Odzvati se morajo na dogodke, ustvariti stanje stroj in izvajati pogoste čakalne zanke.
Pri drugih komponentah morate na primer, ko pokličete povezavo, bodisi počakati, da pride do dogodka povezave, bodisi počakati v zanki, da lastnost pokaže, da je prišlo do povezave. Z Indyjem lahko pokličete metodo Connect in počakate, da se vrne. Povračilo bo izdano, če je povezava uspešna ali če pride do težave, se pojavi izjema. Zato je delo z Indyjem zelo podobno delu z datotekami. Indy vam omogoča, da vso kodo postavite na eno mesto, namesto da bi jo razpršili po različnih dogodkih. Poleg tega je Indy zelo preprost in najbolj priročen pri delu z nitmi.
Kako drugačen je Indy?
Kratek pregled · Uporabljajo se blokirni klici · Niso usmerjeni na dogodke - obstajajo dogodki, vendar se uporabljajo za informativne potrebe in v resnici niso potrebni. ·Zasnovan za niti - Indy je zasnovan za niti, vendar se lahko uporablja brez niti. Zaporedno programiranje
Podroben pregled
Indy ne uporablja le blokiranja klicev (sinhrono), ampak deluje tudi tako. Tipična seja Indy je videti takole:
začnite z IndyClient
Povežite se; poskusite
// Naredi svoje stvari tukaj
končno Odklopi; konec;
konec;
Z drugimi komponentami je videti takole:
procedure TFormMain.TestOnClick(Pošiljatelj: TComponent);
začeti
začnite s SocketComponent
Povežite se; poskusi
medtem ko niste povezani, začnite
če je napaka, potem začni
Prekini;
konec;

OutData:= "Podatki za pošiljanje";
medtem ko se dolžina (OutData) > 0 začne
Application.ProcessMessages;
konec;
končno Odklopi; konec;
konec;
konec;
procedure TFormMain.OnConnectError;
začeti
IsError:= True;
konec;
procedure TFormMain.OnRead;
var
i: Celo število;
začeti
i:= SocketComponent.Send(OutData);
OutData:= Kopiraj(OutData, i + 1, MaxInt);
konec;
Številne komponente ne opravljajo zelo dobrega dela pri izolaciji programatorja od sklada. Številne komponente, namesto da bi uporabnika izolirale od zapletenosti sklada, preprosto prepustijo uporabniku samemu ali zagotovijo ovoj nad skladom.
Indy poseben način
Indy je od začetka zasnovan tako, da je večniten. Gradnja strežnikov in odjemalcev v Indyju je podobna gradnji strežnikov in odjemalcev v Unixu. Aplikacije Unix običajno kličejo sklad neposredno z malo ali brez abstraktne plasti.
Običajno imajo strežniki Unix enega ali več procesov poslušanja, ki spremljajo dohodne zahteve odjemalcev. Za vsako stranko, ki ji je treba postreči, a nov proces. To naredi programiranje preprosto, vsak proces za samo eno stranko. Vsak proces teče v lastnem varnostnem kontekstu, ki ga nastavi proces poslušanja ali proces na podlagi obstoječih pravic, identitete ali drugih stvari.
Strežniki Indy delujejo na približno enak način. Windows za razliko od Unixa ne more dobro razmnoževati procesov, dobro pa deluje z nitmi. Strežniki Indy ustvarijo ločeno nit za vsako odjemalsko povezavo.
Strežniki Indy dodelijo nit poslušanja, ki je ločena od niti glavne kode programa. Nit poslušanja posluša dohodne zahteve strank. Za vsakega odjemalca, na katerega se odzove, se ustvari nova nit, ki služi odjemalcu. Ustrezni dogodki se nato servisirajo v kontekstu tega toka.
Pregled stranke Indy
Indy je zasnovan tako, da zagotavlja zelo visoko raven abstrakcije. Zapletenost in podrobnosti sklada TCP/IP so programerju skrite. Običajno je tipična odjemalska seja v Indyju videti takole:
začnite z IndyClient
Gostitelj:= "zip.pbe.com"; // Gostitelj za klic
Vrata:= 6000; // Vrata za klic strežnika
Povežite se; poskusite
// Naredi svoje stvari tukaj
končno Odklopi; konec;
konec;
Pregled strežnika Indy
Komponente strežnika Indy ustvarijo poslušajočo nit, ki je izolirana od glavne niti programske kode. Nit poslušanja posluša dohodne zahteve strank. Za vsakega odjemalca, na katerega se odzove, se ustvari nova nit, ki služi odjemalcu. Ustrezni dogodki so nato servisirani v kontekstu te niti.

Praktični primeri
Naslednji primeri bi vam morali pomagati pri začetku uporabe komponent za enostaven za uporabo, ampak za prikaz primerov, izdelanih kot enostavne aplikacije. Nekateri projekti so narejeni za prikaz različnih situacij. Ti primeri so na voljo tudi za prenos kot datoteke zip.
Opomba prevajalca: povezava na spletnem mestu ne deluje.
Primer 1 - Preverjanje poštne številke
Prvi projekt je čim bolj preprost. Iskanje po poštni številki, odjemalec vpraša strežnik, kateremu mestu in državi pripada navedena poštna številka.
Za tiste, ki živijo zunaj ZDA in ne vedo, kaj je poštna številka, je poštna številka tista, ki označuje lokacijo dostave. Poštne številke so sestavljene iz 5 števk.
Protokol
Prvi korak pri izgradnji strežnika in odjemalca je razvoj protokola. Za standardne protokole je to opredeljeno z ustreznim RFC. Za poštno številko je protokol opredeljen spodaj.
Večina komunikacijskih protokolov deluje v besedilni način. Izmenjava pomeni, da se posreduje ukaz, kot odgovor pa status in morda podatki. Protokoli niso omejeni na izmenjavo, vendar se še vedno uporablja golo besedilo. Protokol za določanje poštne številke je tudi tekstovni. Navadno besedilo omogoča preprosto odpravljanje napak v protokolih in omogoča komunikacijo med različnimi programskimi jeziki in operacijskimi sistemi.
Po vzpostavitvi povezave strežnik pošlje pozdravno sporočilo in nato sprejme ukaz. Ta ukaz je lahko "ZipCode x" (kjer je x poštna številka) ali "Quit". Kot odgovor na ukaz ZipCode se pošlje odgovor v obliki ene vrstice z odgovorom oz prazna vrsticače koda ni najdena. Ukaz Quit povzroči, da strežnik prekine povezavo. Strežnik lahko sprejme več ukazov, preden se pošlje ukaz Quit.
Izvorna koda strežnika

enota ServerMain;

vmesnik

uporablja

vrsta

TformMain = class(TForm)

IdTCPServer1: TIdTCPServer;

procedure FormCreate(Sender: TObject) ;

procedure FormDestroy(Sender: TObject) ;

procedure IdTCPServer1Connect(AThread: TIdPeerThread) ;

zasebno

ZipCodeList: TStrings;

javnosti

konec ;

FormMain: TformMain;

izvajanje

(R*.DFM)

procedure TformMain.IdTCPServer1Connect (AThread: TIdPeerThread) ;

začeti

AThread.Connection .WriteLn ( "Strežnik Indy Zip Code Ready." );

konec ;

SCommand: niz;

začeti

SCommand:= ReadLn ;

konec ;

konec ;

konec ;

procedure TformMain.FormCreate (Pošiljatelj: TObject) ;

začeti

ZipCodeList:= TStringList.Create ;

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

konec ;

procedure TformMain.FormDestroy (Pošiljatelj: TObject) ;

začeti

ZipCodeList.Free ;

konec ;

konec.

Edini deli v projektu, specifični za Indy, so komponenta IdTCPServer1, metodi IdTCPServer1Connect in IdTCPServer1Execute.
Obrazec vsebuje komponento IdTCPServer1 tipa TIdTCPServer. Naslednje lastnosti so bile spremenjene: ·Active = True – Po zagonu aplikacije strežnik posluša. ·DefaultPort = 6000 – vrednost vrat za ta projekt. Strežnik posluša zahteve odjemalcev na teh vratih.
Metoda IdTCPServer1Execute je povezana s strežnikovim dogodkom OnExecute. Dogodek OnExecute se sproži, ko je odjemalska povezava sprejeta. Dogodek OnExecute se razlikuje od drugih dogodkov, ki jih poznate. OnExecute se izvaja v kontekstu niti. Dogodek niti se dvigne in dobi argument AThread, posredovan metodi. To je pomembno, ker se lahko hkrati izvede več dogodkov OnExecute. To je narejeno tako, da lahko strežnik deluje brez ustvarjanja nove komponente. Obstajajo tudi metode, ki jih je mogoče preglasiti pri konstruiranju dedičev.
Dogodek OnConnect se sproži, ko je bila povezava sprejeta in zanjo ustvarjena nit. IN ta strežnik to se uporablja za pošiljanje pozdravnega sporočila stranki. Po želji lahko to storite tudi v dogodku OnExecute.
Dogodek OnExecute se lahko sproži večkrat, dokler se povezava ne prekine ali izgubi. To odpravlja potrebo po preverjanju povezave za prekinitev ali izgubo v zanki znotraj dogodka.
IdTCPServer1Execute uporablja dve osnovni funkciji, ReadLn in WriteLn. ReadLn prebere niz iz povezave, WriteLn pa pošlje niz v povezavo.
sCommand:= ReadLn;
Zgornja koda vzame niz od odjemalca in ga postavi v lokalno spremenljivko niza sCommand.

če SameText (sCommand, "QUIT" ), potem začni

end else if SameText (Copy (sCommand, 1 , 8 ) , "ZipCode " ) then begin

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

konec ;


Nato se sCommand preveri za veljavne ukaze.
Če je ukaz "Quit", se izvede prekinitev povezave. Po prekinitvi povezave branje ali pisanje ni dovoljeno. Ko se dogodek konča, ga poslušajoča nit ne kliče več, ampak počisti nit in prekine povezavo.
Če je ukaz »ZipCode«, se ekstrahira parameter za ukazom in pregleduje se tabela glede prisotnosti mesta in države. Mesto in država se nato posredujeta odjemalcu ali pa se posreduje prazen niz, če ni ujemanja.
Nato se metoda zapre. Strežnik bo ponovno dvignil dogodek takoj, ko bo prispel nov ukaz, kar bo odjemalcu omogočilo pošiljanje več ukazov.
Izvorna koda odjemalca

enota ClientMain;

vmesnik

uporablja

Windows, sporočila, SysUtils, razredi, grafika, kontrolniki, obrazci, pogovorna okna,

StdCtrls, ExtCtrls, IdAntiFreezeBase,

IdAntiFreeze, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient;

vrsta

TformMain = class(TForm)

Naročnik: TIdTCPClient;

IdAntiFreeze1: TIdAntiFreeze;

Panel1: TPanel;

Panel2: TPanel;

MemoInput: TMemo;

LboxResults: TListBox;

Panel3: TPanel;

Gumb1: TButton;

Gumb2: TButton;

Oznaka1: TLabel;

procedure Button2Click(Sender: TObject) ;

procedure Button1Click(Sender: TObject ) ;

zasebno

javnosti

konec ;

FormMain: TformMain;

izvajanje

(R*.DFM)

procedure TformMain.Button2Click (Pošiljatelj: TObject) ;

začeti

MemoInput.Clear ;

LboxResults.Clear ;

konec ;

procedure TformMain.Button1Click (Pošiljatelj: TObject) ;

I: celo število;

S: niz;

začeti

ButnLookup.Enabled := true ; poskusi

LboxResults.Clear ;

začnite s stranko

Povežite se; poskusi

LboxResults.Items.Add(ReadLn);

for i:= 0 za memoInput.Lines .Count - 1 se začne

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

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

S:= ReadLn ;

če je s = "" potem začni

S:= "-- Za to poštno številko ni bilo mogoče najti vnosa.";

konec ;

LboxResults.Items.Add(s);

LboxResults.Items.Add("");

konec ;

WriteLn("Zapri");

končno Odklopi; konec ;

konec ;

končno butnLookup.Enabled := true ; konec ;

konec ;

konec.


Edini deli, specifični za odjemalsko komponento, so metoda Button1Click.
Komponenta Client je tipa TIdTCPClient in je nameščena na obrazcu. Naslednje lastnosti so bile spremenjene: · Gostitelj = 127.0.0.1 – strežnik se nahaja na istem računalniku kot odjemalec. ·Vrata = 6000 - Vrata strežnika
Metoda Button1Click je povezana z dogodkom OnClick komponente Button1. Ko kliknete gumb, se ta metoda pokliče. Indy del te metode je mogoče zmanjšati na naslednje: 1. Povežite se s strežnikom (Connect;) 1. Preberite pozdrav s strežnika. 1. Za vsako vrstico, ki jo uporabnik vnese v TMemo: 1. Pošiljanje zahteve strežniku (WriteLn("ZipCode " + memoInput.Lines[i]);) 1. Branje odgovora s strežnika (s:= ReadLn; ) 1. Pošiljanje ukaza Quit (WriteLn("Quit");) 1.Disconnect (Disconnect;)
Testiranje
Ta primer je bil preizkušen in deluje z nameščenim TCP/IP. Lahko ga spremenite tako, da deluje prek omrežja iz enega računalnika v drugega. Z zagonom strežnika na drugem računalniku in spremembo imena ali IP-ja strežnika na odjemalcu.
Če želite preizkusiti projekte, prevedite in zaženite strežnik. Nato prevedite in zaženite odjemalca. V polje za beležko vnesite svojo poštno številko in pritisnite tipko za iskanje.
Odpravljanje napak
Besedilne protokole je zelo enostavno odpraviti, ker jih je mogoče preizkusiti s pomočjo Telneta. Če želite to narediti, je dovolj, da poznate vrata strežnika. Strežnik za iskanje poštne kode posluša na vratih 6000.
Ponovno zaženite strežnik za iskanje poštnih številk. Nato odprite konzolo (npr. okno Dos). Zdaj vnesite:
telnet 127.0.0.1 6000
Zdaj ste povezani s strežnikom. Nekateri strežniki pošljejo tudi pozdravno sporočilo. Nekateri ne. Vnesenih vrstic ne boste videli. Večina strežnikov ne odmeva, da bi prihranili promet. Vendar pa lahko spremenite nastavitve telneta tako, da nastavite možnost "Echo On". V različnih odjemalcih telneta se to naredi drugače, nekateri pa te funkcije sploh nimajo. Zdaj vnesite:
poštna številka 37642
Videli boste odgovor strežnika:
CHURCH HILL, TN
Za prekinitev povezave s strežnikom vnesite:
prenehati
Primer 2 - dostop do baze podatkov
Ta primer posnema strežnik, ki mora izvajati naloge blokiranja, ki niso klici vtičnice. Mnogi strežniki so prisiljeni delati v takih pogojih. Strežniki, ki potrebujejo dostop do podatkovne baze, klicev zunanjih procedur ali izračunov, pogosto ne morejo prekiniti teh klicev, ker so zunanji klici ali zaradi kompleksnosti tega. Dostopa do baze podatkov ni mogoče razdeliti na majhne koščke in razvijalec mora počakati na konec operacije z bazo. To ni značilnost le klicev baze podatkov, ampak tudi drugih operacij, kot so stiskanje, izračuni in druga obdelava iste vrste.
Za namene predstavitve si predstavljajmo, da strežnik izvede klic baze podatkov, ki traja 5 sekund. Če poenostavimo, naredimo to preprosto s premorom, za to uporabimo funkcijo Sleep(5000), namesto da bi dejansko poklicali.
Ta primer zahteva tudi manj podrobnosti kot prejšnji primer, ker mnogi koncepti še niso razumljeni.
Vir

glavna enota;

vmesnik

uporablja

Windows, sporočila, SysUtils, razredi, grafika, kontrolniki, obrazci, pogovorna okna,

IdBaseComponent, IdComponent, IdTCPServer;

vrsta

TformMain = class(TForm)

IdTCPServer1: TIdTCPServer;

procedure IdTCPServer1Execute(AThread: TIdPeerThread) ;

zasebno

javnosti

konec ;

FormMain: TformMain;

izvajanje

(R*.DFM)

procedure TformMain.IdTCPServer1Execute (AThread: TIdPeerThread) ;

I: celo število;

začeti

z AThread. Povezava se začne

WriteLn("Pozdravljeni. Strežnik DB pripravljen.") ;

I:= StrToIntDef(ReadLn, 0);

// Spanje je nadomeščeno za dolg DB ali drug klic

Spanje (5000);

WriteLn(IntToStr(i * 7));

konec ;

konec ;

konec.

Ker se dogodek Execute zgodi v kontekstu niti, je koda za obdelavo lahko poljubne dolžine. Vsaka stranka ima svojo nit in ne blokira drugih strank.
Testiranje
Če želite preizkusiti strežnik DB, ga prevedite in zaženite. Povežite se z njim prek Telneta na vrata 6001. Strežnik se bo odzval s pozdravnim sporočilom. Vnesite številko. Strežnik bo "obdelal" vašo zahtevo in odgovoril v 5 sekundah.

Komponente Indy, uporabljene v Delphiju 6.

Poleg osnovnih internetnih storitev in protokolov obstaja širok nabor dodatnih storitev, katerih zmogljivosti internetni razvijalci pogosto uporabljajo. Poleg tega možnost prikaza informacij z uporabo brskalnika ni vedno sprejemljiva rešitev za internetne aplikacije. V tem primeru je smiselno uporabiti internetno infrastrukturo za izmenjavo podatkov in zagotoviti prikaz informacij prek kompleksnejših odjemalskih aplikacij, razvitih na primer v Delphiju.

Recimo, da morate implementirati specializirano strežniško logiko, ki ni vključena v standardne spletne strežnike. Za rešitev tega razreda problemov Delphi vključuje knjižnico Internet Direct (Indy) podjetja Nevrona Designs (http://www.nevrona.com/Indy/). Ta knjižnica, razvita posebej za Borland Delphi, ima že osem različic, od katerih je zadnja vključena v novo različico Delphija. Nabor komponent je razdeljen v tri skupine: odjemalec (Indy Client), strežnik (Indy Servers) in pomožni (Indy Misc).

Odjemalci in strežniki Indy

Večina komponent Indy Client in Indy Servers je parov, ki ustrezajo odjemalskim in strežniškim delom protokolov in storitev (z izjemo nekaterih, predvsem strežniških komponent, kot sta TunnelMaster in TunnelSlave), in omogočajo uporabo protokolov, kot je TCP/IP , UDP, NNTP, SMTP, FTP, HTTP, kot tudi storitve ECHO, FINGER, WHOIS itd.

Komponente odjemalca Indy so napisane z uporabo vtičnic. Vtičnica na strani odjemalca zahteva povezavo s strežnikom. Če je povezava vzpostavljena, lahko odjemalec in strežnik začneta izmenjevati sporočila. Ta sporočila so drugačne narave, vendar običajno izmenjava poteka z uporabo določenega protokola (na primer HTTP)

TIdTCPClient in TIdTCPServer

Te komponente se uporabljajo za podporo enega od glavnih omrežnih protokolov - TCP (Transmission Control Protocol), in so tudi osnovni razredi za komponente TIdSMTP in TIdFTP. Razred TIdTCPServer ima lastnost ThreadMgr, ki je privzeto nastavljena na nič. Če je ThreadMgr enak nič, ko je TIdTCPServer omogočen, bo razred TIdThreadMgrDeafault ustvarjen implicitno. V nasprotnem primeru se uporablja nameščeni upravljalnik procesov.

TIdUDPClient in TIdUDPServer

Te komponente se uporabljajo za podporo omrežnega protokola UDP (User Datagram Protocol) in so tudi osnovni razredi za številne druge komponente Indy.

TIdChargenServer

Komponenta se uporablja za ustvarjanje naključnih simbolov, običajno za namene testiranja.

TIdDayTime in TIdDayTimeServer

Komponente se uporabljajo za zagotavljanje časovne storitve. Odjemalec zahteva, strežnik pa sporoči trenutni datum in uro.

Reševalec TIdDNSR

To je odjemalska komponenta, ki služi zahtevam strežnika DNS (Domain Name Service). Poizvedbe strežnika DNS so zasnovane tako, da zamenjajo ime računalnika z njegovim naslovom IP. TIdDNSResolver je potomec razreda TIdUDPClient.

TIdDICTServer

Strežniška komponenta, ki podpira Dictionary Server Protocol (DICT), slovar na strežniški strani, ki temelji na protokolu TCP, ki odjemalcu omogoča dostop do slovarja naravnega jezika.

TIdDISCARDServer

Komponenta strežnika, ki podpira strežnik zapisov. Posnetke je mogoče uporabiti kot orodje za odpravljanje napak in merjenje. Evidenčna služba morebitne podatke enostavno preda tistemu, ki jih je pripravljen prejeti.

TI dEcho in TI dECHOServer

Komponente so zasnovane za zagotavljanje odzivne storitve, ki se običajno uporablja za preverjanje zdravja omrežja. Odjemalec pošlje besedilno sporočilo strežniku, strežnik vrne sporočilo odjemalcu. Če je sporočilo popačeno, omrežje ne deluje pravilno.

TIdFinger in TIdFingerServer

Komponente so zasnovane tako, da zagotavljajo protokol, ki uporabniku omogoča poizvedovanje po podatkih o prisotnosti drugih uporabnikov v sistemu. Nekateri strežniki obravnavajo takšne zahteve strank. Uporaba tega para komponent vam bo omogočila servisiranje zahtev odjemalcev, ki določajo prisotnost drugih uporabnikov v sistemu.

TIdFTP

Komponenta vključuje popolno podporo za protokol za prenos datotek - FTP (File Transfer Protocol). Podprt je pasivni in aktivni prenos podatkov, pa tudi operacije, kot sta GET in PUT, brisanje imenikov, pridobivanje kvot, velikosti datotek in imenikov. TI dFTP za delovanje uporablja razred TIdSimpleServer. Ko poteka prenos datoteke FTP, se odpre sekundarna povezava TCP za prenos podatkov in se zapre, ko so podatki preneseni. Ta povezava se imenuje »podatkovna povezava«, ki je edinstvena za vsako datoteko, ki se prenaša.

TIdGopher in TIdGopherServer

Te komponente so zasnovane za zagotavljanje omrežnega protokola, ki ga je pred kratkim iz WWW (svetovnega spleta) izpodrinil protokol HTTP. Strežnik, ki izvaja ta protokol, zagotavlja hierarhično porazdeljen sistem za podporo pretoka dokumentov. Primer uporabe tega para komponent, ki se nahaja v imenikih \demos\indy\GopherClient in \demos\indy\GopherServer, prikazuje, kako lahko s tem protokolom v lokalnem omrežju posredujete informacije o datotekah v vašem računalniku, vključno z zaprtimi .

TIdHostNameServer

Komponenta strežnika, zasnovana za posredovanje imena lokalnega strežnika odjemalcem.

TIdHTTP in TIdHTTPServer

Komponente se uporabljajo za zagotavljanje omrežnega protokola HTTP (podprti sta različici 1.0 in 1.1, vključno z operacijami GET, POST in HEAD). Poleg tega je zagotovljena podpora za avtentikacijo in uporabo proxy strežnikov. Strežniška komponenta se uporablja za zagotavljanje storitev drugemu spletnemu strežniku, ki podpira dani protokol. TIdHTTPServer olajša izvajanje funkcij, kot so piškotki, upravljanje stanja itd.

TIdIcmpClient

Komponenta odjemalca, zasnovana za zagotavljanje internetnega protokola za nadzorna sporočila (ICMP), ki se uporablja za izvajanje operacij ping in sledenje omrežju.

TIdPOP3

Odjemalska komponenta, zasnovana za zagotavljanje poštnega protokola (POP), vključno s podporo za kodiranje in dekodiranje MIME ter prenos večbajtnih znakov.

TIdIMAP4Server

Komponenta strežnika, zasnovana za podporo operacij IMAP (Internet Message Access Protocol) na strežniku. Protokol omogoča iskanje e-poštnih sporočil na strežniku. Razlika med protokoloma IMAP in POP je v tem, da protokol POP zahteva dodaten pomnilnik za shranjevanje podatkov, protokol IMAP pa dostopa do strežnika namesto do odjemalske naprave. IMAP4 je bil ustvarjen, da bi nadomestil POP3, vendar POP3 še danes ostaja pogosto uporabljen standard.

TIdIRCServer

Komponenta strežnika, zasnovana za podporo najpogosteje uporabljenih operacij storitev na internetu, običajno imenovanih klepet. Komponenta zagotavlja osnovne gradnike za strežnik IRC (Internet Relay Chat).

TIdMappedPortTCP

Komponenta strežnika, zasnovana za ustvarjanje preslikanih vrat, ki se pogosto uporabljajo v proxy strežnikih. Metode te komponente vam omogočajo, da ena vrata preslikate v druga. Na primer, vrata 80 bi lahko preslikali v vrata 3000 in vse zahteve do prvih vrat (vrata 80) bi bile posredovane drugim vratom (vrata 3000).

TIdNNTP in TIdNNTPServer

Te komponente so potrebne za podporo protokola Network News Transfer Protocol (NNTP), ki se uporablja v novičarskih storitvah. Odjemalska komponenta vključuje podporo za kodiranje in dekodiranje MIME ter podporo za večbajtne znake in alternativna kodiranja. Komponenta strežnika vam omogoča ustvarjanje strežnikov novic. Pomembno je omeniti, da TIdNNTPServer ni strežnik novic s polnimi funkcijami, ampak komponenta, ki zagotavlja osnovno funkcionalnost za tak strežnik.

TIdQOTD in TIdQOTDServer

Komponente se uporabljajo za zagotavljanje storitve Citat dneva. Odjemalska komponenta se poveže s primerkom strežniške komponente, da pridobi dnevno ponudbo. Vsak primerek strežnika vsebuje edinstveno bazo podatkov o citatih.

TIdSMTP

Odjemalska komponenta, zasnovana za uporabo v aplikacijah SMTP (Simple Mail Transfer Protocol), ki zagotavlja podporo za preverjanje pristnosti, kodiranje in dekodiranje MIME ter podporo za večbajtne znake.

TIdSNTP

Odjemalska komponenta, zasnovana za zagotavljanje SNTP (Simple Network Time Protocol) – časovne storitve. Uporablja se lahko za povezavo s katero koli časovno storitvijo za določitev trenutnega datuma in ure.

TIdSimpleServer

Komponenta strežnika, ki zagotavlja lahek strežnik TCP. Omogoča vam organiziranje povezave od točke do točke. Uporablja se za ustvarjanje strežnikov z enim uporabnikom, kar pomeni, da lahko služi samo eni povezavi hkrati. Za razliko od komponente TIdTCPServer ne ustvarja sekundarnih procesov, ko čaka na zahteve strank in obdeluje te zahteve. Z drugimi besedami, če strežnik streže zahtevo od odjemalca in v tem času drug odjemalec kontaktira z njim za povezavo, potem bo blokiran do konca obdelave prve zahteve.

TIdTelnet in TIdTelnetServer

Komponenta odjemalca se uporablja za organiziranje oddaljenih sej na drugem računalniku, vključno s pogajanji konzole in preverjanjem pristnosti. Komunikacijski protokol predvideva prisotnost osebe, ki interaktivno komunicira s strežnikom. Komponenta odjemalca nima podpore za zaslon ali emulacije terminala, ampak preprosto zagotavlja povezavo s strežniškim delom. Običajno se strežniški protokol TIdTelnetServer uporablja za organiziranje oddaljenih baz podatkov z besedilnim vmesnikom za interaktivno interakcijo s strankami.

TIdTime in TIdTimeServer

Odjemalska komponenta je alternativa komponenti TIdSNTP za določanje časa. Pomembno je omeniti, da sta formata obeh protokolov različna. TIdTime temelji na formatu RFC 868 (vrne čas v internem standardu OS UNIX in izvede vse potrebne pretvorbe). Komponenta strežnika je po delovanju podobna strežniku DayTime. Lahko se uporablja za implementacijo časovne storitve na lokalnem računalniku. Dodatna koda ni potrebna, samo ustvarite primerek TIdTimeServer, ki bo vrnil čas notranje ure strežniškega računalnika.

TIdTrivialFTP in TIdTrivialFTPServer

Te komponente so potrebne za organizacijo preprostega protokola za prenos datotek. Odjemalska komponenta tega protokola se uporablja za povezavo s primerkom ustrezne strežniške komponente. Protokol je namenjen zasebnim, lahkim, lokalnim primerom prenosa datotek, na primer v lokalnih omrežjih ali za nalaganje (nalaganje) usmerjevalnih tabel v usmerjevalnike. Zaradi oslabljenih lastnosti tega protokola njegova uporaba ni priporočljiva pri uporabi algoritmov za preverjanje pristnosti ali drugih varnostnih mehanizmov. Glavni namen tega protokola je prenos datotek na strojno napravo z namenom njenega spreminjanja.

TIdTunnelMaster in TIdTunnelSlave

Komponente strežniškega tunela se uporabljajo v strežnikih proxy za organiziranje več logičnih povezav prek enega fizičnega (tunela). Te razrede je mogoče uporabiti za različne namene, na primer za organizacijo skrivne povezave prek neskrivnih kanalov.

TIdWhois in TIdWhoIsServer

Ta odjemalska komponenta se poveže s katerim koli standardnim strežnikom Whois, kar vam omogoča pridobivanje informacij o domenah. Komponenta strežnika zagotavlja osnovno funkcionalnost strežnika NIC.

Indy Razno

Stran Indy Miscellaneous Components vključuje BASE64, UUE, Quoted Printable in druge pogoste komunikacijske formate e-pošte, kodirnike (MD2, MD4 in MD5) za kriptografske standarde, ki se uporabljajo za shranjevanje gesel in elektronskih podpisov v nepreklicni (težki za dešifriranje) obliki, kot tudi številne druge uporabne komponente in pripomočke, ki se pogosto uporabljajo pri razvoju internetnih aplikacij.

TIdAntiFreeze

Zaradi algoritmov komponent Indy, ki temeljijo na blokih, se pogosto zdi, da je aplikacija obstala, medtem ko povezava deluje. Če želite odpraviti uporabo sekundarnih procesov (niti) pri organiziranju komunikacij, da preprečite zamrznitev aplikacije, je dovolj, da navedeno komponento postavite na obrazec.

Komponenta deluje tako, da razčlenjuje zahteve iz sklada protokolov TCP/IP in pošilja sporočila aplikaciji med zakasnitvijo, ko so zunanje povezave blokirane, kar ustvarja iluzijo izvajanja kode. Ker komponenta vpliva na blokirane povezave samo za glavni proces, uporaba TIdAntiFreeze v sekundarnih procesih aplikacije ni potrebna. Ne pozabite, da komponenta TIdAntiFreeze upočasni povezave, ker se glavni proces občasno prekine zaradi obdelave sporočil. Iz tega sledi, da je treba paziti, da aplikacija, ki se razvija, ne porabi preveč časa za obdelavo sporočil, vključno z OnClick, OnPaint, OnResize itd. Do neke mere je to mogoče nadzorovati z lastnostmi razreda TIdAntiFreeze. Uporaba te komponente ni obvezna, vendar vam omogoča, da rešite problem sinhronizacije povezav z vizualnim vmesnikom aplikacije.

TIdDateTimeStamp

Razred za izvajanje matematike datuma in časa v zvezi z dejstvom, da internetni protokoli uporabljajo različne oblike zapisa datuma in časa; poleg tega se lahko odjemalci in strežniki nahajajo v različnih časovnih pasovih.

TIdIPWatch

Je komponenta, ki temelji na časovniku in nenehno spremlja spremembe naslova IP računalnika. Dogodki komponent se zgodijo, ko je zaznana sprememba. Ta komponenta se običajno uporablja za ugotavljanje, ali je računalnik povezan z internetom ali katerim koli drugim omrežjem. Do spremembe naslova IP v tej situaciji lahko pride zaradi naslova IP, ki ga dodeli strežnik DHCP (Dynamic Host Configuration Protocol) pri povezovanju z novim omrežjem.

TIdLogDebug

Namen te komponente je prestreči dogodke katere koli odjemalske ali strežniške komponente in postaviti zapis dogodka v navedeno datoteko. Ta komponenta je zelo uporabna za odpravljanje napak komponent Indy.

TIdMessage

Komponenta se uporablja v kombinaciji z drugimi komponentami za pravilno dešifriranje ali kodiranje sporočil. To so lahko komponente POP, SMTP in NNTP. Razred podpira šifriranje in dešifriranje MIME, večbajtne znake in kodiranje ISO.

TidNetworkCalculator

Ena redkih komponent Indy, ki jih je mogoče uporabiti pri gradnji aplikacij. Omrežni kalkulator se lahko uporablja za izračune naslovov IP, vključno z omrežnimi maskami, podomrežji, omrežnimi razredi itd.

TIdThreadMgrDefault

Komponenta privzeto zagotavlja nadzor nad sekundarnimi procesi. Ustvari se, ko katera koli komponenta Indy, ki podpira upravljanje procesov, nima definiranega primerka razreda TIdThreadManager. Komponenta ponuja le osnovne zmožnosti za upravljanje sekundarnih procesov: ustvarjanje in uničenje le-teh na zahtevo.

TIdThreadMgrPool

Naprednejša komponenta za upravljanje procesov kot TIdThreadMgrDefault, ker združuje procese, namesto da jih ustvarja ali uničuje na zahtevo.

TIdVCard

VCard je elektronski ekvivalent vizitke in lahko vsebuje osebne in grafične podatke lastnika.

TIdIMFDekoder

Zasnovan za dekodiranje internetnih sporočil. Je potomec razreda TIdCoder, tako kot vse druge komponente kodirnika. Razred TIdCoder dekodira v skladu s standardom formata besedilnih sporočil ARPA RFS-822, predlaganim avgusta 1982, in standardom za sporočanje USENET RFC 1036, predlaganim decembra 1987.

Komponenta razširja razred TIdCoder, da omogoči zaznavanje formata RFS-822 s kontekstom glave, zagotavlja način dešifriranja ob prejemu ter šifriranje in dešifriranje MIME. Komponenta TIdIMFDecoder se uporablja v razredu TIdMessageClient za dekodiranje prejetih in poslanih sporočil.

TIdQuotedPrintableEncoder

QuotedPrintableEncoder vam omogoča dešifriranje besedila v določenem formatu. Lahko služi kot samostojna komponenta z določeno vrsto kodiranja, ki omogoča prenos sporočil, ki vsebujejo novo vrsto kodiranja.

TIdBase64Encoder

Implementira drug šifrirni algoritem, ki omogoča prenos nenatisljivih znakov.

TIdUUEncoder

Implementira enega prvih šifrirnih algoritmov, UU kodiranje. Včasih se uporablja pri pošiljanju člankov novičarski službi.

TIdXXEncoder

Ta metoda šifriranja verjetno ne bo nikoli uporabljena. V bistvu je to isto kodiranje UU, vendar z drugačno tabelo šifriranja.

TIdCoderMD2

Komponente z različnimi vrstami šifrirnega algoritma MD (Message Digest). Vsi temeljijo na naključnem vrstnem redu, so enosmerni in nimajo algoritmov za dešifriranje.

Komponente protokolarnih odjemalcev in strežnikov se lahko uporabljajo za razvoj strežniških in odjemalskih internetnih aplikacij, skupaj ali namesto osnovnih (ClientSocket, ServerSocket) in drugih komponent iz interneta in palete Fastnet. Komponente Indy ne uporabljajo arhitekture WebBroker, saj implementirajo nizkonivojsko podporo za internetne protokole in storitve neposredno v svoji izvorni kodi (izvorne kode so vključene).

TIdConnectionInterceptOpenSSL in TIdServerInterceptOpenSSL

Protokol SSL – Secure Sockets Layer, ki zagotavlja tajnost in zanesljivost komunikacije med dvema aplikacijama, ima dva sloja. Na nizki ravni večslojnega transportnega protokola (kot je TCP) je SSL snemalni protokol in se uporablja za enkapsulacijo različnih protokolov višje ravni. Prednost SSL je v tem, da je neodvisen aplikacijski protokol, vendar je poleg SSL mogoče uporabiti protokol višje ravni.

SSL zagotavlja komunikacijsko varnost, ki ima tri glavne funkcije: zagotavljanje zaupne povezave; šifriranje z javnim ključem (uporablja se za potrditev identitete prejemnika); podpora za zanesljivost prenosa podatkov.

  • Za šifriranje podatkov se uporablja simetrična kriptografija (npr. DES, RC4 itd.).
  • Digitalni podpis je zagotovljen z uporabo asimetričnega šifriranja z javnim ključem (na primer RSA, DSS itd.).
  • Zanesljivost komunikacije, prenos sporočila vključuje preverjanje celovitosti sporočila s pomočjo popravnih kod MAC, varnih zgoščevalnih funkcij (npr. SHA, MD5 itd.) z uporabo izračunov MAC.

V kombinaciji s HTTP in avtentikacijo strežnika SSL zagotavlja potrebne funkcije šifriranja in nadalje vzdržuje vzpostavljeno povezavo z navzkrižnim preverjanjem identitete spletnega strežnika itd. Pomembno je razumeti, da SSL ščiti samo komunikacijo med prenosom podatkov in ne nadomešča drugih varnostnih mehanizmov.

Komponenti TIdConnectionInterceptOpenSSL in TIdServerInterceptOpenSSL zagotavljata tako povezave na strani odjemalca kot na strani strežnika z uporabo protokola SSL. Upoštevati je treba, da sta komponenti TIdConnectionInterceptOpenSSL in TIdServerInterceptOpenSSL na voljo samo v Delphiju 6 in ne v Kylixu. To je posledica zapletenosti protokola, ki v primeru izvedbe Windows temelji na funkcijah operacijskega sistema.

Primere uporabe komponent Indy lahko najdete v imenikih /Delphi6/Demos/Indy. Skupaj knjižnica Indy v različici 8.0 vsebuje 69 komponent. Navedeno je, da bo navedena knjižnica v različici 9.0 vsebovala 86 komponent. Vse komponente so poenotene in vključene tako v Delphi 6 kot v Kylix, kar omogoča njihovo uporabo za razvoj večplatformskih aplikacij. Vse komponente Indy podpirajo večnitnost.

Komponente Indy izvajajo skoraj vse funkcije, ki jih najdemo v komponentah Internet in Fastnet, kot je jasno prikazano v tabeli.

Hitre komponente Indy komponente Namen komponent
1 TserverSocket, TClientSocket TIdTCPserverSocket, TIdTCPClientSocket Interakcija med dvema računalnikoma (odjemalec in strežnik) po protokolu TCP/IP
2 TNMDayTime TIdDayTime, TIdDayTimeServer Poizvedite strežnik za trenutni čas
3 TNMEcho TIdEcho, TIdEchoServer Uporablja se za komunikacijo z odzivnim strežnikom
4 TNMFinger TIdFinger, TIdFingerServer Uporablja se za pridobivanje informacij o uporabniku iz internetnega iskalnega strežnika
5 TNMFTP TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer Zagotovite prenos datotek s protokolom FTP
6 TNMHTTP TIdHTTP, TIdHTTPServer Za izmenjavo podatkov uporabite protokol HTTP
7 TNMMsgServ, TNMMsg Uporablja se za prenos preprostih besedilnih sporočil od odjemalca do strežnika
8 TNMNNTP TIdNNTP, TIdNNTPServer Podpira izmenjavo podatkov s strežnikom novic
9 TNMPOP3 TIdPOP3 Uporablja se za prejemanje e-pošte s poštnega strežnika s protokolom POP3
10 TNMSMTP TIdSMTP Uporablja se za pošiljanje e-pošte prek internetnega poštnega strežnika
11 TNMStrm, TNMStrmServ Prenaša binarne podatke, zapisane v tok z uporabo protokola TCP/IP
12 TNMUDP TIdUDP, TIdUDPServer Prenesite podatke s protokolom UDP
13 TpowerSock, TNMGeneralServer Komponentno inkapsulirani razredi, ki so osnova za pisanje lastnih odjemalcev (Powersock) in strežnikov (NMGeneralServer)
14 TNMUUProcesor TIdUUEncoder, TIdUUDecoder Pretvori binarne datoteke v format MIME ali UUENCODE
15 TNMURL Pretvori nize v obliko HTML in izvede obratno pretvorbo

Izjema so razredi, kot so TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, ki izvajajo zastarele protokole ali imajo funkcionalnost implementirano v veliki skupini alternativnih razredov.

Za razliko od svojih predhodnikov – komponent interneta in Fastneta pa Indy vsebuje bogatejše strežniške komponente in komponente za transkodiranje in šifriranje podatkov ter podporo za avtentikacijo (paleta Indy Misc). Kot je razvidno iz zgornje tabele, glavne protokole in storitve zagotavljajo ne le odjemalske, ampak tudi strežniške komponente. To so časovne storitve, odzivne storitve, pridobivanje informacij o uporabnikih, pa tudi protokoli HTTP, NNTP, UDP in celo najpreprostejša različica FTP.

Nekaj ​​primerov uporabe komponent Indy

V komponentah Indy, ki jih vsebuje Delphi, je naslov IP definiran v lastnosti Host, običajno samo v odjemalskih aplikacijah. Komponente, ki gostujejo v strežniku, imajo metode, ki vam omogočajo, da začnete ali ustavite preverjanje ustreznih vrat – na primer, če spremenite lastnost Active komponente IdTCPServer, se zažene ali ustavi preverjanje ustreznih vrat. Ko je povezava med odjemalcem in strežnikom vzpostavljena, se lahko začne prenos podatkov.

Komponente Indy dajejo velik poudarek varnosti in zanesljivosti pri delu s podatki. Na primer, komponenta IdTCPClient ima metode Connect in Disconnect. Uporaba tehnike programiranja, kot je spodnja koda s strani odjemalca:

s TCPClient začnite povezovanje; poskusite lstMain.Items.Add(ReadLn); končno Odklopi; konec; konec;

in z uporabo lastnosti Connection, posredovane kot parameter primerku AThread razreda TIdPeerThread s strani strežnika:

z AThread.Connection naredite začetek WriteLn("Pozdrav iz strežnika Basic Indy Server."); Odklopi; konec;

računate lahko bodisi na normalno izvedbo povezave bodisi na pravilno obravnavo napak.

Upoštevajte metodi ReadLn in WriteLn ustreznih razredov - podobni sta standardnim V/I stavkom Pascal. To je poklon tehniki programiranja UNIX, kjer se večina sistemskih operacij izvede z branjem in pisanjem v ustrezne datoteke.

Tako kot komponente Fastnet imajo razredi komponent Indy dogodke, ki jih je mogoče uporabiti za zagotavljanje upravljanja dogodkov. Na primer, lahko uredite, da se sporočilo prikaže na obrazcu, ko se povezujete z odjemalcem:

procedure TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Serving client ]"; konec;

Indy ponuja komponente, ki izvajajo protokole z deli odjemalca in strežnika, ki so edinstveni za to knjižnico. Komponenti TIdGopherServer in TIdGopher, zahvaljujoč metodam GetExtendedMenu, GetFile, GetMenu, GetTextFile na strani odjemalca in ReturnGopherItem, SendDirectoryEntry na strani strežnika, pomagata pri ogledu datotek različnih vrst, vključno s tistimi, ki so označene kot skrite, kot tudi imenikov na oddaljeni računalnik (podobno kot ukaz dir *.* v operacijskem sistemu MS-DOS).

Z uporabo komponent IdSMTP in IdMessage lahko preprosto ustvarite lastno spletno aplikacijo, ki lahko pošilja pošto po protokolu SMTP.

V tem primeru je za generiranje sporočila odgovoren razred IdMessage (ena od 23 komponent s strani Indy Misc), ki izhaja iz njegovega imena, IdSMTP pa za organizacijo povezave s poštnim strežnikom.

Tehnologija, uporabljena v Indyju, uporablja zaklepanje operacij branja in pisanja. Vsaka operacija Connect, uporabljena v Indyju, čaka na dokončanje povezave. Ko delate s komponentami odjemalca Indy, morate običajno storiti naslednje:

  • zahtevajte povezavo s strežnikom;
  • pošiljanje zahtev za branje in pisanje na strežnik (odvisno od vrste strežnika se korak izvede enkrat ali večkrat ponovi);
  • prekinite povezavo s strežnikom in prekinite povezavo.

Komponente Indy so zasnovane tako, da zagotavljajo izjemno visoko raven abstrakcije. Zapletenost in podrobnosti sklada TCP/IP so programerju skrite, tako da se lahko osredotoči na trenutno nalogo.

Naslednji majhen primer prikazuje tipično sejo gradnika odjemalca:

z IndyClient do begin Host:= "zip.pbe.com"; // Gostitelj za klic Port:= 6000; // Vrata za klic strežnika na Connect; poskusi // Vaša koda gre tukaj končno Odklopi; konec; konec;

V primeru, tudi če povezava s strežnikom ni vzpostavljena, bo povezava elegantno prekinjena zaradi uporabe stavka try-finally.

Komponente strežnika Indy opisujejo različne modele strežnikov, ki jih je mogoče uporabiti glede na vaše potrebe in protokol, ki ga uporabljate.

TIdTCPServer je najpogosteje uporabljena strežniška komponenta, ki ustvari sekundarni proces, neodvisen od glavnega aplikacijskega procesa. Ustvarjeni proces čaka na dohodne zahteve potencialnih strank. Individualni sekundarni proces se ustvari za vsako stranko, na zahtevo katere odgovarja. Dogodki, ki se zgodijo med procesom vzdrževanja, so povezani s kontekstom ustreznih procesov.

Z drugimi besedami, za vsako povezavo odjemalca razred TIdTCPServer uporabi edinstveno sekundarno nit tako, da pokliče obravnavo dogodkov OnExecute te niti. Formalni parameter metode OnExecute je sklic na primerek razreda Athread, ki ustreza ustvarjeni niti. Lastnost Connection tega razreda je sklic na razred TIdTCPConnection, katerega primerek je ustvarjen za obdelavo zahteve odjemalca. TIdTCPConnection podpira branje in pisanje prek povezave ter vzpostavljanje in prekinitev komunikacijske seje.

Protokol UDP deluje brez predhodne vzpostavitve povezave s strežnikom (vsak poslan paket je neodvisen nabor podatkov in ni del večje seje ali povezave). Medtem ko TIdTCPServer ustvari ločene niti za vsako povezavo, TIdUDPServer uporablja glavno nit ali eno sekundarno nit, ki obravnava vse zahteve protokola UDP. Ko je TIdUDPServer aktiven, se ustvari nit za poslušanje dohodnih paketov UDP. Za vsak prejeti paket se sproži dogodek OnUDPRead v glavni niti ali v kontekstu poslušajoče niti, odvisno od vrednosti lastnosti ThreadedEvent. Ko je ThreadedEvent ovrednoten na False, se dogodek zgodi v glavni niti, sicer pa v poslušajoči niti. Medtem ko se dogodek obdeluje, so druge operacije strežnika blokirane. Zato je pomembno zagotoviti, da se postopki OnUDPRead izvajajo čim hitreje.

Če morate ustvariti novo odjemalsko aplikacijo za obstoječi strežnik z uporabo obstoječega protokola, je vaša naloga izključno razvoj in odpravljanje napak v odjemalski aplikaciji. Ko pa moramo razvijati tako odjemalske kot strežniške aplikacije z uporabo obstoječega ali novega protokola, se soočimo s klasičnim problemom »kokoš in jajce«. Kje začeti programirati - pri odjemalcu ali pri strežniku?

Očitno je treba na koncu ustvariti tako odjemalca kot strežnik. Za številne aplikacije, zlasti tiste, ki uporabljajo besedilni protokol (kot je HTTP), je lažje začeti graditi aplikacijo z načrtovanjem strežnika. In za odpravljanje napak obstaja priročen odjemalec, ki že obstaja. To je konzolna aplikacija Telnet, ki je na voljo v sistemih Windows in UNIX.

Če vnesete ukaz konzole telnet 127.0.0.1 80 z naslovom IP lokalnega računalnika in številko vrat 80, ki jih privzeto uporabljajo spletni strežniki, se bo aplikacija odzvala z besedilom, prikazanim na sl. 6, v primeru operacijskega sistema Windows 2000 in IIS 5.0.

Če želite ustvariti najpreprostejši strežnik z uporabo komponent Indy, potrebujete:

Če morate zasnovati strežnik, ki ne bo le pravilno obvestil svojih odjemalcev, ko se povezava prekine, temveč jim bo zagotovil tudi informacije o napakah, ki so se zgodile, uporabite stavek poskusi razen namesto poskusi končno - na primer kot prikazano v naslednjem primeru:

procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: niz; začnite z AThread.Connection do poskusite poskusite s:= ReadLn; // Izvedite nalogo strežnika tukaj // če ni sprožene nobene izjeme, // izpišite odgovor strežnika WriteLn(s); razen na e: Izjema do begin WriteLn(e.Message); end; //on end; //poskusite, razen končno Prekini povezavo; konec; konec;

Ta majhen primer prikazuje korake za ustvarjanje preprostega besedilnega strežnika, pa tudi, kako v njem odpraviti napake.

Zgoraj opisani strežnik je tipičen primer organizacije sodobnega porazdeljenega računalništva.

Značilnosti ustvarjanja večplastnih aplikacij

V zadnjem času se za zadovoljevanje zahtev strank vse pogosteje uporablja več strežnikov. Strežnik te vrste, ko prejme zahtevo odjemalca in jo delno pripravi za nadaljnjo obdelavo, vzpostavi stik z drugim strežnikom in mu pošlje preoblikovano zahtevo ali zahteve. Strežnik drugega nivoja lahko nato komunicira z drugimi strežniki. Tako lahko govorimo o večnivojski strežniški arhitekturi.

Nato bomo ustvarili strežnik za dostop do podatkov, katerega namen je vračanje podatkov iz baze podatkov. Vendar pa ta strežnik ne bere neposredno datotek baze podatkov ali piše vnje. Namesto tega komunicira s strežnikom baze podatkov in išče podatke, ki jih zahteva odjemalec.

Tako začnemo razvijati aplikacijo s trinivojsko arhitekturo. Če želite ustvariti strežnik baze podatkov z uporabo komponent Indy, potrebujete:

  1. Ustvarite nov projekt.
  2. Postavite primerek komponente TIdTCPServer iz palete Indy Servers na glavni obrazec projekta.
  3. Nastavite lastnost DefaultPort instance razreda TIdTCPServer1 na 6001 (priporočljivo je dodeliti velike vrednosti, da se izognete podvajanju številk vrat v različnih aplikacijah) in nastavite lastnost Active na true.
  4. Projektu dodajte nov modul tako, da izberete Datoteka | Novo | Data Module in vanj postavite primerke komponent SQLConnection in SQLDataSet z zavihka dbExpress na paleti komponent.
  5. Nastavite lastnost ConnectionName razreda SQLConnection na IBLocal in LoginPrompt na False. Če niste konfigurirali IBLocal v zbirki podatkov employee.gdb, najprej dokončajte ta postopek.
  6. Lastnost SQLConnection razreda SQLDataSet nastavite na SQLConnection1 in stavku SQL dodelite lastnost CommandText: izberite CUSTOMER, CONTACT_FIRST, CONTACT_LAST od CUSTOMER, kjer CUST_NO = :cust.

Pozdravljeni vsi skupaj!

Pri razvoju naslednjega spletnega projekta se je pojavila naloga - implementirati odjemalsko programsko opremo v Delphi, ki bi prenašala podatke na strežnik z metodo POST. Aplikacija mora prenašati besedilo in nalagati datoteke na spletni strežnik.

Implementacija takšnega pošiljanja podatkov z uporabo strežniških jezikov spletni razvoj(na primer PHP) je precej preprosta, če pa morate napisati večuporabniško programsko opremo, ki temelji na aplikacijah in je v interakciji s strežnikom, je nekoliko bolj zapletena. Metoda neposrednega povezovanja z bazo podatkov in preko FTP na strežnik iz Delphija ni več potrebna, ker ni varen, nezanesljiv (spreminjanje gesel, podatkov o povezavi itd.) in ustvarja dodatne. težave z združljivostjo programske opreme na strani odjemalca. Da bi rešil problem, sem se odločil napisati skripte (strežniški del) v PHP, ki bodo obdelovale dohodne POST zahteve in vrne rezultat odjemalcu (aplikaciji Delphi). Prednosti tega pristopa so, da se vse povezave in obdelava podatkov odvijajo na strežniku, kar je veliko bolj varno kot direktna »povezava«.

Ko sem začel googlati, je bilo veliko razpršenih informacij opuščenih, večinoma po forumih, a je bilo vse v koščkih. Nekaj ​​je bilo gotovo, da bo uporabljen Indy, in sicer komponenta IdHTTP z implementirano metodo POST. Pravzaprav je vse preprosto, ta metoda vzame dva parametra Url vira in DataStream (podatkovni tok) ter vrne rezultat v besedilni obliki (lahko je tudi HTML koda strani). Glavna stvar je bila pravilna tvorba DataStream (tok prenesenih podatkov), vendar so se ob tem pojavile dodatne pasti, in sicer rusko kodiranje (če ni bilo dobro). Tu se je začela zabava večurnega potepanja po internetu. Na splošno dovolj klepetanja, pojdimo k praksi in implementaciji programske opreme.

Program je torej preprost. Podatke mora poslati strežniku z metodo POST, podatki vsebujejo " Naslov " (vrstica), " Opis » ( večvrstično besedilo) In grafično datoteko(jpg,png,gif-binarni podatki). Strežnik mora te podatke sprejeti, obdelati, shraniti grafično datoteko na strežnik in vrniti odgovor. Kot odgovor bomo aplikaciji vrnili Delphi, isto besedilo le z dodanimi oznakami in povezavo do prenesene datoteke. Nič drugega.

Začnimo z implementacijo strežniškega dela (podobno kot API spletnega mesta). Odprite katero koli urejevalnik besedil(beležnica) in vanjo zapišite naslednjo kodo:

"; ) else ( echo "Naslov: Manjka"."
"; ) //Preveri vhodne podatke glede prisotnosti podatkov polja "vsebina" if (!empty($_POST["content"]))( echo "Vsebina: ".$_POST["content"]."
"; ) else ( echo "Vsebina: manjka"."
"; ) //Preveri dohodne podatke za prisotnost priložene datoteke "file" if (!empty($_FILES["file"])) ( $finfo = pathinfo($_FILES["file"]["name" ]); / /pridobite informacije o datoteki (ime, končnica itd.) //Preverite vrsto datoteke na seznamu dovoljenih vrst (IMPROVIZACIJA:)), če (stripos("jpgpnggif",$finfo["extension"] )==0)( echo ">>>>>>>Neveljavna vrsta datoteke<<<<<<<<"; exit; //Если не допустим тип, полностью останавливаем скрипт } $fname = "files/" . "testimgfile." . $finfo["extension"]; //формируем путь и новое имя файла move_uploaded_file($_FILES["file"]["tmp_name"],$fname);//сохраняем временный файл "tmp_name" в файл $fname echo "http://".$_SERVER["HTTP_HOST"]."/".$fname; //возвращаем полный путь к файлу } ?>

Opomba! Pri shranjevanju (preko beležnice) morate določiti kodiranje "UTF-8", sicer bodo težave s prikazom cirilice!

Scenarij je poskušal dati podrobne komentarje. Kopirajte ta skript na vaš spletni strežnik, če ga nimate, lahko za test uporabite moj skript, ki se nahaja na: http://api..php

Postavitev uporablja naslednje komponente: Label, Button (2 kosa), Edit (2 kosa), Memo (2 kosa), CheckBox, OpenDialog, IdHTTP. Poimenujte naslednje komponente (lastnost " Ime”):

  1. Uredi (naslov) – Ime=naslov;
  2. Uredi (pot do datoteke) Ime = imgfile;
  3. Beležka (vsebina)Ime = vsebina;
  4. Beležka (rezultat) – Ime = odgovor;
  5. Gumb (…) – Ime = chkfile;
  6. Gumb (POST) – Ime = PostBut;
  7. OpenDialog (pogovorno okno za izbiro datoteke) – Ime = PictDialog;

Pustimo IdHTTP1 in CheckBox1 nespremenjena (utrujeni! :)))).

Da ne bi slučajno" Uredi» pot do Edit( imgfile), nastavite lastnost ReadOnly na True. Prav tako pri imgfile in chkfile Nastavite lastnost Enabled na false. Aktivirali jih bomo s pomočjo CheckBoxa, tj. Zagotovili bomo možnost izbire, ali želite naložiti sliko ali ne.

Za OpenDialog( PictDialog) morate filter (lastnost filtra) nastaviti na naslednji način:

Prava vizualna priprava je končana! Začnimo s kodiranjem!

V projektu bomo ustvarili podatkovni tok z uporabo vrste, vključene v Indy - TidMultiPartFormDataStream.Čeprav smo naleteli na možnosti izvedbe z uporabo TStream, delo z TidMultiPartFormDataStream – lažje!

Da bo ta vrsta na voljo našemu projektu, moramo v Uporabe dodati naslednjo knjižnico: IdMultipartFormData.

Za CheckBox1 ustvarite dogodek OnClick (z dvojnim klikom miške na predmet) in temu dogodku dodajte naslednjo kodo:

Procedure TForm1.CheckBox1Click(Pošiljatelj: TObject); začetek //naredi aktivne ali neaktivne elemente poti do datoteke in pogovorne gumbe imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; konec;

Tukaj aktiviramo objekte imgfile inchkfile odvisno od prisotnosti kljukice (če je potrditveno polje označeno, postanejo predmeti aktivni).

Zdaj pa organizirajmo izbor slik. Če želite to narediti, na gumbu ustvarite dogodek OnClick chkfile(tudi z dvojnim klikom na predmet) in napišite naslednje:

Procedure TForm1.chkfileClick(Pošiljatelj: TObject); začetek //odprite pogovorno okno in vnesite celotno pot do datoteke v imgfile(TEdit) if PictDialog.Execute then imgfile.Text:= PictDialog.FileName; konec;

Ta dogodek bo sprožil pogovorno okno za izbiro slike in če uporabnik klikne " Odprto", potem bo dodana pot do te datoteke imgfile.

In zdaj smo prišli do zadnjega gumba "POST". Ustvarite dogodek OnClick za ta gumb in dodajte to kodo:

Procedure TForm1.PostButClick(Pošiljatelj: TObject); var dataPost:TIdMultiPartFormDataStream; begin dataPost:=TIdMultiPartFormDataStream.Create; dataPost.AddFormField("title",title.Text,"utf-8").ContentTransfer:= "8bit"; dataPost.AddFormField("content",content.Text,"utf-8").ContentTransfer:= "8bit"; if CheckBox1.Checked and (trim(imgfile.Text)="") then //preverjanje, ali je datoteka izbrana ali ne, begin ShowMessage("Izbrati morate grafično datoteko!"); izhod; konec; če je CheckBox1.Checked potem dataPost.AddFile("file",imgfile.Text,""); //dodajte polje z odgovorom datoteke.Besedilo:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Free; end;

Torej, po vrsti (čeprav obstajajo komentarji):

Datapost – objekt vrste TIdMultiPartFormDataStream. Omogoča ustvarjanje strukture zahteve POST, sestavljene iz polj različnih vrst.

dataPost . AddFormField (" naslov ", naslov . Besedilo ," utf -8 "). ContentTransfer := " 8 bit "; – doda polje z imenom “title” v DataPost, vrednost iz “title.Text”, nastavi kodiranje poslanih podatkov na “utf-8” (parameter je neobvezen, vendar brez njegove eksplicitne navedbe se cirilica prenaša z vprašaj “?”) in zelo pomembna metoda "Prenos vsebine". Brez te metode se podatki pošljejo strežniku " abrakadabra" Upoštevajte, da se mora ime polja (»naslov«) na pošiljateljski strani ujemati z imenom, določenim v skriptu: $_POST["naslov"].

Podatki se prenašajo podobno kot v polju »vsebina«.

dataPost . AddFile (" mapa ", imgfile . Besedilo ,"") – s to vrstico ustvarimo tok s podatki iz datoteke.

To je to, podatki so ustvarjeni, vse kar ostane je, da jih prenesete v skript na strežniku in prejmete odgovor:

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

Ker TMemo ne razume oznake za prelom vrstice "
", bomo uporabili funkcijo " ", da jo nadomestimo z razumljivimi prelomi vrstic "#13#10".

Ko je vse končano, počistite pomnilnik iz objekta DataPost z vrstico:

datapost.Brezplačno;

Čeprav se bo v našem primeru to zgodilo samodejno na koncu postopka, pa vseeno ...

Dejanski rezultat programa na zaslonu:

Tako lahko na strežnik pošljemo poljubno količino podatkov ali datotek, obdelamo te podatke na strežniku in prijavimo aplikaciji rezultat skripta. Lahko je celo samo 0 ali 1, kar bo aplikaciji signaliziralo, da se odzove naprej.

Vse. Srečno vsem. Upam, da so bile informacije koristne in da jih boste uporabili.

Končni primer in skript lahko prenesete.

Celotna koda modula:

Enota PostUnit; vmesnik uporablja Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient, IdHTTP, IdMultipartFormData, Vcl.ExtDlgs; tip TForm1 = class(TForm) IdHTTP1: TIdHTTP; naslov: TEdit; vsebina: TMemo; PostBut: TButton; odgovor: TMemo; Oznaka1: TLabel; Oznaka2: TLabel; Oznaka3: TLabel; imgfile: TEdit; chkfile: TButton; Oznaka4: TLabel; CheckBox1: TCheckBox; PictDialog:TOpenDialog; procedure PostButClick(Pošiljatelj: TObject); procedure chkfileClick(Pošiljatelj: TObject); procedure CheckBox1Click(Pošiljatelj: TObject); zasebno ( Private declarations ) javno ( Public declarations ) konec; var Form1: TForm1; implementacija ($R *.dfm) procedure TForm1.CheckBox1Click(Sender: TObject); začetek //naredi aktivne ali neaktivne elemente poti do datoteke in pogovorne gumbe imgfile.Enabled:=CheckBox1.Checked; chkfile.Enabled:=CheckBox1.Checked; konec; procedure TForm1.chkfileClick(Pošiljatelj: TObject); začetek //odprite pogovorno okno in vnesite celotno pot do datoteke v imgfile(TEdit) if PictDialog.Execute then imgfile.Text:= PictDialog.FileName; konec; procedure TForm1.PostButClick(Pošiljatelj: TObject); var dataPost:TIdMultiPartFormDataStream; begin dataPost:=TIdMultiPartFormDataStream.Create; dataPost.AddFormField("title",title.Text,"utf-8").ContentTransfer:= "8bit"; dataPost.AddFormField("content",content.Text,"utf-8").ContentTransfer:= "8bit"; if CheckBox1.Checked and (trim(imgfile.Text)="") then //preverjanje, ali je datoteka izbrana ali ne, begin ShowMessage("Izbrati morate grafično datoteko!"); izhod; konec; če je CheckBox1.Checked potem dataPost.AddFile("file",imgfile.Text,""); //dodajte polje z odgovorom datoteke.Besedilo:= StringReplace(idHTTP1.Post("http://api..php",dataPost),"
",#13#10,); datapost.Free; konec; konec.

Serge Dosyukov Mike Pham

Ta članek vam pokaže, kako ustvarite samostojno spletno storitev z uporabo kompleta Indy in Delphi 7 ter kako uporabite komplet Indy za podporo spletnih storitev, ki temeljijo na SOAP Delphi 7. Za več informacij o ustvarjanju spletnih storitev si oglejte odličen članek Nicka Hodgesa na spletnem mestu skupnosti Borland: Shakespeare na spletu.

Prej ali slej boste morda morali ustvariti strežnik, ki je samostojen strežnik HTTP in podpira spletne storitve. Na primer, morda boste želeli ustvariti aplikacijski strežnik, ki temelji na SOAP, za n-nivojsko aplikacijo, zgrajeno z Delphijem.

Uvod

Delphijeva spletna pomoč nudi odlična navodila po korakih o tem, kako ustvariti spletno storitev, strežnik MIDAS (COM, DCOM), vendar praktično ni informacij o ustvarjanju samostojne n-nivojske aplikacije MIDAS, ki temelji na SOAP.

Prej objavil Dave Nottage. Ta članek je opisal zamisel o tem, kako ustvariti spletno storitev v Delphiju 6 s podporo SOAP in zmožnostjo objave vmesnikov SOAP modula Datamodule, kar pomeni, da vam je ta članek omogočil, da se naučite, kako ustvariti svoj n-nivoj MIDAS sistemi.

Borlandov Delphi 7 in novi komplet Indy imata vgrajeno podporo za to funkcionalnost.

Kljub vgrajeni podpori pa ta funkcija ni dokumentirana.

Nedavne objave na omrežni konferenci Borland in iskanje po spletu z Googlovim strežnikom so avtorjem omogočili, da razvijejo način za pretvorbo obstoječe kode iz Delphi 6 v Delphi 7. Toda vse ima svoj čas.

glavna ideja

Ta članek je prvi del tridelne serije. Opisuje glavne določbe. Drugi in tretji del bosta namenjena nekaterim problemom in načinom njihovega reševanja. Začnimo z opisom glavne ideje.

  • biti samostojen strežnik HTTP;
  • uporabite Indy kot platformo;
  • podpora objavljanju prek protokola SOAP;
  • biti sposoben objavljati podatkovne module SOAP, kar bi vam omogočilo ustvarjanje lastnega n-nivojskega strežnika, ki temelji na SOAP/HTML.

HTTP strežnik in SOAP

Veliko ljudi pozna Indy in so že uporabljali komponente THTTPServer. To komponento je enostavno postaviti na obrazec za prijavo, toda kako omogočiti, da podpira SOAP? V imeniku "C:Program FilesBorlandDelphi7SourceIndy" najdete datoteko IdHTTPWebBrokerBridge.pas. To je točno tisto, kar potrebujete.

Ta datoteka ni del izvršljive datoteke Indy, zato jo morate vključiti v svoj trenutni projekt kot standardno projektno datoteko. (Za prevajanje projekta boste potrebovali tudi datoteko IdCompilerDefines.inc.) Te datoteke je treba kopirati v trenutni imenik projekta. Za povečanje hitrosti bodo morda potrebne spremembe kode, zato je najbolje, da te datoteke hranite ločeno od distribucije Indy.

V nadaljevanju je opisana izvedba nadomestne komponente iz strežnika THTTPServer, razširjene za podporo paketov SOAP, imenovane TIdHTTPWebBrokerBridge. Ta konstrukt je razred, ki podeduje TCustomHTTPServer in podpira osnovno vezavo zahtev.

Ker ta razred ni dostopen iz palete, ga boste morali pri izvajanju kode definirati kot običajni objekt.

Ta objekt je mogoče uporabiti na povsem enak način kot običajni THTTPServer, z izjemo tistih dodatnih lastnosti, ki omogočajo delovanje s SOAP.
Vendar si najprej poglejmo pripravo potrebne kode.

WebBroker in Indy

Za tiste, ki so že ustvarili spletne storitve, veste, da uporabljate WebBroker. Delphi 7, tako kot Delphi 6, uporablja arhitekturo WebBroker za podporo SOAP.

Zato morate ustvariti modul TWebModule in vanj postavite naslednje tri komponente: THTTPSoapDispatcher, THTTPSoapPascalInvoker in TWSDLHTMLPublish. Vse so na voljo na zavihku WebServices v paleti komponent. Po povezavi SOAPDispatcherja s SOAPPascalInvokerjem je obrazec za prijavo pripravljen. Končni rezultat bi moral biti podoben temu, kar je prikazano na naslednji sliki:

(modul uWebModule.pas)

Najbolje je, da pustite vse tako, kot je, saj za ta obrazec ni treba spreminjati ali izvajati kode po meri.

WebModule in Indy

Pojdimo k drugemu delu kode, ki je potrebna za implementacijo strežnika HTTP.

Kot lahko vidite, ima TIdHTTPWebBrokerBridge metodo RegisterWebModuleClass, ki vam omogoča, da registrirate svoj spletni modul in ga daste na voljo strežniku.

Tako morate po izdelavi objekta strežnika fServer le poklicati razred fServer.RegisterWebModuleClass (TwmSOAPIndy).

Opomba. V običajni implementaciji TIdHTTPWebBrokerBridge bo objekt TwmSOAPIndy ustvarjen vsakič, ko bo prejeta zahteva. Očitno to ni potrebno. Zato je mogoče razred spremeniti, da se zagotovi trajna izdelava tega objekta, dokler obstaja objekt Strežnik. Priporočljivo je, da se za več informacij obrnete na dokumentacijo o izvedbi razreda.

Ali je strežnik pripravljen?