Primatelj je prekinuo prijenos podataka. Tko je vodio analizu dnevnika? Osnovni načini održavanja trajne veze

Mnogi sudionici u nabavi, bez obzira na iskustvo, susreću se s problemom ispravnog rada na elektroničkoj trgovačkoj platformi. Te se pogreške mogu otkriti u bilo kojem trenutku, uključujući i tijekom elektroničkog trgovanja.

Posljedice mogu biti vrlo različite, naime:

Prijava za sudjelovanje na natječaju nije dostavljena na vrijeme
Izgubljena e-dražba
Državni ugovor nije potpisan na vrijeme

Tri najčešća problema pri radu s elektroničkim potpisima

Potvrda o sudioniku u nabavi nije prikazana na elektroničkoj platformi
Elektronički potpis ne potpisuje dokumente

Zapravo, može biti mnogo više pogrešaka, ali ćemo analizirati glavne i njihove uzroke, a također ćemo navesti moguće načine za uklanjanje problema.

Najvažnije je zapamtiti da za ispravan rad elektroničkog potpisa morate koristiti preglednik Internet Explorer ne nižu od verzije 8 i, po mogućnosti, ne višu od 11 (s verzijom 11 nema jamstva za stabilan rad potpisa ).

Certifikat ključa za potpisivanje nije vidljiv na stranici prilikom pokušaja prijave u sustav

U ovom slučaju pogrešku uzrokuje nekoliko razloga, a to su:

Neispravna konfiguracija certifikata ključa za potpisivanje
Internetski preglednik nije ispravno konfiguriran
Nedostaje korijenski certifikat Tijela za izdavanje certifikata

Kako riješiti problem?

Prije svega, morate provjeriti jeste li ispravno instalirali javni dio certifikata u osobni putem CIPF-a (Crypto Pro). U tom slučaju, verzija instaliranog programa odgovara vrsti operativnog sustava koji imate.

Zatim, u postavkama preglednika Internet Explorer, trebate dodati adrese stranica pouzdanim stranicama i omogućiti sve ActiveX kontrole.

Elektronički potpis daje grešku prilikom potpisivanja dokumenata

Obično se ova pogreška pojavljuje u nizu slučajeva:

Licenca programa CryptoPro je istekla
Umetnut je medij s drugim certifikatom

Kako to popraviti?

Da biste to učinili, morate dobiti novu licencu kontaktiranjem Centra za certificiranje. Nakon uspješno primljene licence potrebno je pokrenuti CryptoPro i unijeti serijski broj licence.

U drugom slučaju potrebno je provjeriti sve zatvorene spremnike (medije) umetnute u USB konektor računala i provjeriti je li odabran ispravan certifikat.

Sustav daje grešku prilikom prijave na elektroničku platformu

Ova greška može biti uzrokovana kombinacijom gore navedenih razloga. Kao što praksa pokazuje, takva se pogreška prvenstveno pojavljuje zbog neispravno instalirane Capicom knjižnice. Preporučujemo da provjerite je li biblioteka instalirana na vašem računalu i da obratite pozornost na potrebu kopiranja 2 sistemske datoteke s nastavkom .dll u jednu od Windows mapa kada koristite 64-bitni sustav.

Kako biste izbjegli takve pogreške, prije postavljanja elektroničkog potpisa pročitajte o postavljanju i postavljanju elektroničkog potpisa ili naručite informacije o izdavanju i postavljanju elektroničkog potpisa u našoj tvrtki.

S novim formatom pohrane, datoteka dnevnika može dosegnuti stotine gigabajta. Vrijeme uzorkovanja za to će biti jako dugo, i nastaje problem: rad svih korisnika prestaje.

Znakovi ovog problema su:

Nemoguće je ući u bazu podataka.

Gotovo 100% aktivnost diska na kojem se nalazi log datoteka i aktivno čitanje log datoteke od strane rmngr procesa.
Ovu stavku možete provjeriti pomoću monitora resursa (Upravitelj zadataka - Performanse - Otvoreni monitor resursa) na kartici "Disk".
U grupi "Uređaji za pohranu" morate obratiti pozornost na stupac "Aktivno vrijeme (%)".
U grupi "Rad diska" morate obratiti pozornost na stupce "Čitanje" i "Datoteka". Možete sortirati prema stupcu "Čitanje". Među prvim redcima s najbržom brzinom čitanja bit će rmngr proces. Zatim morate pogledati naziv datoteke koja se čita, ona će odgovarati dnevniku registracije određene infobaze.

U administrativnoj konzoli klastera poslužitelja 1C:Enterprise, na popisu sesija, gotovo svi korisnici će imati veliku i približno istu vrijednost u stupcu "DBMS Captured" ili u stupcu "Call Time (current)".

Ako se otkrije problem, morate:

Zapamtite UID sustava informacijske sigurnosti koji čita rmngr proces.

Počnite prikupljati dnevnik procesa za EXCP događaje, ako već nije započelo.

Izvezite sve sesije na problematičnom poslužitelju ILI na problematičnoj informacijskoj sigurnosti pomoću administracijske konzole klastera poslužitelja 1C:Enterprise, u slučaju da su potrebni dodatni podaci za analizu.

Ponovno pokrenite uslugu 1C:Enterprise.

Prikupite tehnološki dnevnik za vrijeme ponovnog pokretanja poslužitelja 1C:Enterprise.

Analizirajte tehnološki dnevnik: potražite riječi “UnloadRegistrationLog” ili “UnloadEventLog”.

Primjer:

29:40.069000-0,EXCP,4,proces=rphost, p:processName=ib_accounting ,t:clientID=114396,t:applicationName=1CV8C, t:nazivračunala=COMP ,t:connectID=109127,SessionID=1, Usr=IvanovII ,AppID=1CV8C,ClientID=114389,Exception=NetDataExchangeException,Descr=Prijemnik je prekinuo prijenos podataka.,Context="Form.Call: ExternalReport.RegistrationLogAnalysis.Form.Module.BackgroundTaskRun

GeneralForm.ReportForm.Form: 1242: ReportOptions.GenerateReportInBackground(ReportGenerationParameters, BackgroundTaskResult.ResultAddress);

GeneralModule.ReportOptions.Module: 2544: Formacija = GenerateReport(Parametri, False, False);

GeneralModule.ReportOptions.Module: 2060: ReportObject.AssembleResult(Result.TabularDocument, Result.Decryption);

ExternalReport.AnalysisLog.ObjectModule: 64:UploadJournalRegistration(TK, Odabir, Stupci);"

Iz ove linije možete znati tko: Ivanov II, gdje (na kojem računalu): KOMP , u kojoj informacijskoj bazi: ib_računovodstvo pokrenuo analizu dnevnika.

COMET tehnologije omogućuju organiziranje ažuriranja podataka na stranici bez intervencije korisnika.

Chatovi, internetska pošta i višekorisničke administrativne ploče nisu potpuni popis gdje su primjenjivi.

U ovoj seriji članaka detaljno su opisane brojne suptilne točke i rješenja uobičajenih problema.

Što je COMET?

COMET (ili "server push") je metoda prijenosa podataka od poslužitelja do klijenta, na inicijativu poslužitelja.

Na primjer, imate elektroničku trgovinu, a upravitelj može pratiti prijelaze klijenata.
COMET omogućuje menadžeru da odmah, online, upita klijenta o nečemu i ponudi zanimljivu opciju.

"Pokrenuto od poslužitelja" znači da sam klijent ne zahtijeva poslužitelj, on je jednostavno na stranici.

Najstariji primjer COMET-a je chat. Osoba jednostavno ostaje na stranici i prima nove poruke.

COMET se također koristi u admin panelima za obavještavanje drugih posjetitelja o promjenama, za zajedničko uređivanje dokumenata i sl.

Metode provedbe

Postoji mnogo načina implementacije COMET-a. Imaju različite karakteristike, prednosti i nedostatke.
Postoje dvije glavne klase.

Porukom na upit

Preglednik prima svaki događaj na poslužitelju s posebnim zahtjevom. Ovdje postoje dvije glavne metode.

Često glasanje
Duga anketa

Kako bi se smanjio broj potrebnih veza i kašnjenje, poruke o događajima pakiraju se u posebne pakete, "datagrame".
Na primjer, jedna XML poruka može izgledati ovako:

Vasja Zdravo! obrada Obrada završena

Sljedeći put kada se povežete, preglednik odmah prima cijeli paket događaja do danas.

Preglednik održava stalnu vezu s poslužiteljem, takozvanim "kanalom", i preko njega prima događaje.

Komunikacijski kanal se s vremena na vrijeme prekida:

tako da proxy ne pomisli da je veza istekla i prekine je umjesto nas
za brisanje memorije od smeća starih poruka

Osim toga, za mjerenje kašnjenja mreže i praćenje veza, poslužitelj može povremeno slati ping pakete preko ovog kanala.

Osnovni načini održavanja trajne veze:

Beskonačni IFrame
XMLHTTPRequest, interaktivan
Višedijelni XMLHTTP zahtjev
Izvor događaja

Naći ćete ih u drugim člancima u ovom odjeljku.

Problemi uobičajeni za stalne veze

HTTP protokol je izvorno dizajniran tako da jedan zahtjev vraća jednu informaciju. Ali mi želimo puno, pa otuda neke poteškoće...

Proxy međuspremnik

To je rijetko, ali proxy može spremiti u međuspremnik određenu količinu podataka prije nego što ih pošalje klijentu. Na primjer, primajte i šaljite odgovore u blokovima od 2K. U ovom slučaju, poruke će ostati na proxyju i čekati dok ne dosegnu 2K (ili koja god je veličina međuspremnika) bajtova, i tek tada će biti poslane klijentu.

Rješenje je dodati 2K razmaka svakoj poruci.

Nije poznato hoće li ovaj problem utjecati na vas. Nadam se da ne, ali je imperativ imati na umu proxy buffering kao mogući uzrok pritužbi korisnika.

Ne može GZIP

IFrame koji služi za prosljeđivanje poruka NE bi trebao biti komprimiran s gzip/deflate. Drugim riječima, kompresija bi trebala biti onemogućena za URL usluge poruka.

Omogućena kompresija znači da preglednik čeka kraj preuzimanja, a zatim ga dekompresira i prikazuje korisniku. U našem slučaju to je strogo kontraindicirano i nemoguće je zasebno komprimirati dijelove stranice (poruke).

Ovo je nesretna posljedica hakerske prirode iframea. Na primjer, u dugoj anketi kompresija ide dobro jer događaji nisu dio iste stranice.

Međuspremnik stranice poslužitelja

Ne zaboravite onemogućiti međuspremnik poslužitelja. U Apache/PHP - onemogućite izlazni međuspremnik i omogućite ob_implicit_flush:

Dok (@ob_end_flush()) () ob_implicit_flush(1); // i naravno, uklonite ograničenje vremena izvršavanja skripte set_time_limit(0);

COMET: često prozivanje VS trajna veza

Kao i uvijek, prilikom pisanja web aplikacije postavlja se pitanje odabira arhitekture. S jedne strane, rješenja na dugim vezama (sve osim čestog prozivanja) pružaju brzu obavijest. S druge strane... Je li duga veza uvijek bolja od čestog prozivanja?
Rješenje s dugim vezama je naizgled optimalnije, ali je mnogo kompliciranije i ima niz karakteristika.

Provedba duge veze, u pravilu, komplicira arhitekturu. Možda postoji jednostavnije rješenje?
Brojni web poslužitelji su slabo optimizirani za veliki broj dugih veza. Na primjer, koriste se niti ili procesi koji troše fiksnu količinu resursa i ne oslobađaju ih do kraja veze, problem se rješava korištenjem kqueue (FreeBSD) ili epoll (Linux At). razini web poslužitelja, možete koristiti
1. Apache MPM događaj za apache 2.2 (eksperimentalni i ograničeni MPM, posebne niti upravlja slušanjem i Keep-Alive utičnicama)
  ne radi ispravno s mod_perl/mod_php
2. Jetty (Java) / Twisted (Python), nginx i drugi specijalizirani poslužitelji s jednom niti/procesom za mnogo klijenata.
Hoće li trenutna arhitektura poslužitelja podnijeti duge veze? Odgovor nije očit za stotine/tisuće istodobnih veza, ali do, recimo, 100 veza u bilo kojoj arhitekturi je u redu.
Koliko dugo korisnici ostaju na istoj stranici? Tijekom prijelaza, veza će se najvjerojatnije morati ponovo otvoriti u svakom slučaju.
Ako su kašnjenja u isporuci događaja prihvatljiva, možda će često prozivanje biti dovoljno?

Klasični (neovisan o transportu) COMET model

Pogledajmo interakciju klijent-poslužitelj "iz ptičje perspektive", iznad detalja prijenosa podataka, transporta itd. Na primjer, to se radi u specijaliziranom poslužiteljskom push motoru lightstreamer-u.

Veze s poslužiteljem dijele se na dvije vrste

Kontrolna veza - kontrolna veza preko koje klijent šalje zahtjeve poslužitelju. Ovo su uobičajeni AJAX zahtjevi putem XMLHTTPRequesta.
Push veza (kanal) - tok događaja, veza preko koje klijent prima događaje od poslužitelja

Svi događaji na poslužitelju imaju vrstu. Klijent se putem kontrolnih veza može prijaviti i odjaviti na događaje od interesa. Radi praktičnosti, tipovi su organizirani u dijagrame. Na primjer, shema chata može imati vrstu poruke.

Na primjer, sljedeći dijagram opisuje tipičan slijed radnji:

Klijent otvara streaming vezu s poslužiteljem
Klijent se pretplaćuje na događaje tipa Item1 u Schema1
Poslužitelj šalje događaje
Klijent odjavljuje događaje putem nove kontrolne veze
Klijent zatvara vezu

Ili - ovdje je složeniji dijagram u kojem se klijent pretplaćuje na različite vrste događaja:

Lightstreamer koristi iframe kao prijenos. S vremena na vrijeme mora se zatvoriti kako bi se očistili primljeni objekti. Kada se sesija zatvori (isto se događa kada se stranica osvježi u pregledniku), poslužitelj sprema nove događaje u međuspremnik do određenog vremenskog ograničenja i šalje ih čim se otvori nova Stream Connection 2 sesija istog korisnika.

Općenito, međuspremnik događaja je opća tehnika koja vam omogućuje da glatko preživite zatvaranje veze i potrebna je za svaki prijenos.