mesaje de serviciu de documentare telegramă despre mesaje

confirmare de primire

Serverul confirmă, de obicei primirea mesajului de la client (de obicei - RPC-cerere) prin intermediul RPC-răspuns. În cazul în care răspunsul nu este lung, serverul poate trimite mai întâi o confirmare de primire, și după un timp - el, răspunsul RPC.

Clientul confirmă, de obicei primirea mesajului de la serverul (de obicei - RPC-răspuns), adăugarea de confirmare la următorul RPC-cererea în cazul în care acesta este trimis prea târziu (de exemplu, în cazul în care are loc în termen de 60-120 de secunde după ce a primit un mesaj de la server). Cu toate acestea, în cazul în care o lungă perioadă de timp nu există nici un motiv pentru a trimite mesaje de la server, sau dacă mesajele neconfirmate de pe server, acesta devine mult (să zicem, mai mare de 16), clientul trimite o confirmare în sine.

Notificarea ignora mesajul de eroare

În unele cazuri, serverul poate informa clientul pe care le-a trimis un mesaj a fost ignorat dintr-un motiv sau altul. Rețineți că o astfel de notificare poate fi generată în cazul în care mesajul nu a fost decriptat corect de către server.

Aici cod_eroare poate lua, inclusiv următoarele valori:

• 16 - msg_id prea mic (cel mai probabil la client momentul nepotrivit, are sens să-l păstrați în sincronizare, folosind notificări MSG_ID și retrimite mesajul original cu „dreapta» msg_id, sau înveliți-l într-un recipient cu un nou MSG_ID, în cazul în care mesajul original este prea lung de așteptare Trimite client)
• 17 - msg_id prea mare (în cazul anterior: este necesar pentru a sincroniza ora pe client și retrimiteți mesajul cu msg_id dreapta)
• 18 - inferiori doi biți de msg_id incorecte (server teaptă împărțit în 4 MSG_ID posturi client)
• 19 - container msg_id a coincis cu MSG_ID mesaj primit anterior (acest lucru nu ar trebui să fie)
• 20 - mesajul este prea vechi, și este imposibil să se verifice dacă serverul primește un mesaj cu msg_id sau nu
• 32 - msg_seqno prea mic (un server de mesaje a fost deja făcută cu mai puțin msg_id, dar cu seqno, fie cu același ciudat.)
• 33 - msg_seqno prea mare (. Similare: există un mesaj cu un msg_id mare, dar cu mai puțin seqno, fie cu același nui adevărat)
• 34 - așteptat chiar msg_seqno (mesaj nesemnificativ), a primit un ciudat
• 35 - se așteaptă ca msg_seqno ciudat (mesaj semnificativ), a primit o chiar
• 48 - server de sare greșit (în acest caz, este trimis la sarea corectă răspunsul bad_server_salt trebuie să retrimiteți mesajul să-l)
• 64 - containerul greșit.

Așa cum a conceput, valorile sunt grupate pe error_code (error_code >> 4): de exemplu, codurile 0x40..0x4f corespund erorii în container de analiză.

Notificările de a ignora mesajul nu trebuie să fie confirmat (de exemplu, nu sunt semnificative).

Important: În cazul în care serverul a schimbat server_salt. sau în cazul în care clientul momentul nepotrivit, fiecare cerere este primit o notificare de tipul de mai sus. Clientul trebuie să verifice dacă a trimis într-adevăr recent un mesaj specificat MSG_ID, și dacă da - să actualizeze la momentul modificării (diferența dintre ceasul server și client) și sarea de server, pe baza notificării MSG_ID și server_salt care urmează să fie utilizat pentru (re) trimiterea de mesaje viitoare. În acest caz, mesajul original (de exemplu, la care a returnat o notificare de eroare) ar trebui să fie, de asemenea, retrimiterea cu msg_id și / sau server_salt mai adecvate.

În plus, clientul poate actualiza server_salt de valoare. utilizată la trimiterea mesajelor către server, pe baza valorilor din RPC-răspunsurilor sau recipiente care conțin răspuns rpc, cu condiția ca acest răspuns se potrivește cu RPC-adevăr cerere trimis recent. (În caz de dubiu, este mai bine să nu actualizeze, deoarece există riscul de reluare-atac.)

Cerere de informații cu privire la mesajul de stare

În cazul în care una dintre părți pentru o lungă perioadă de timp nu primește informații despre starea mesajelor trimise la ea, ea poate cere în mod explicit de partea opusă:

Ca răspuns la această solicitare conține următoarele informații:

Informații despre starea post mesaj

Aici req_msg_id - cerere msgs_state_req ID. info - un șir de caractere care pentru fiecare din lista de mesaje msg_ids trimis conține exact un octet cu mesaje de stare:

• 1 = Mesajul nu este cunoscută (msg_id este prea mică, partea opusă poate uita)
• 2 = mesaj nu a fost primit (msg_id în domeniul dispozitivelor de identificare stocate, dar partea opusă a unui astfel de mesaj nu este primit cu exactitate)
• 3 = mesaj a fost primit (msg_id este prea mare, partea opusă nu a fost încă cu exactitate)
• 4 = mesaj a fost primit (rețineți că acest răspuns este o confirmare de primire, în același timp)
• +8 = pe mesajul a fost deja trimis o confirmare
• +16 = pe mesajul nu are nevoie de confirmare
• += 32 este deja finalizată sau o solicitare de procesare a RPC conținut într-un mesaj
• +64 = pentru un răspuns semnificativ a fost generat
• +128 = cealaltă parte știe că mesajul a fost primit

Acest răspuns nu necesită confirmare. Prin ea însăși, este o dovadă a msgs_state_req corespunzătoare.

raportarea voluntară a mesajelor de stare

Oricare dintre părți poate informa în mod voluntar cealaltă parte a mesajelor de stare transmise de cealaltă parte.

Lista toate codurile de mesaje cunoscute de cealaltă parte, cu excepția celor pentru care pavilion este setat la 16 sau 128. Cu toate acestea, în cazul în care pavilion 32, dar nu 64, starea mesajului va fi trimis în continuare.

Acest mesaj nu trebuie să fie confirmată.

Extins informații voluntare privind condițiile de un singur mesaj

De obicei, folosit de server pentru a răspunde la reachiziționa posturi msg_id. mai ales dacă acest mesaj a fost generat de răspuns, iar acest răspuns mare. În cazul în care răspunsul este mic, serverul poate repeta în schimb răspunsul în sine.

A doua opțiune este utilizată pentru notificarea mesajelor care au fost create pe server, ca rezultat al RPC-cerere (de exemplu, notificări de mesaje noi) au fost trimise la client ceva timp în urmă, dar acestea nu au fost primite de confirmare.

Acest mesaj nu trebuie să fie confirmată.

O solicitare explicită pentru mesajele de retransmisie

Ca răspuns la petrecere la distanță retransmite mesajele imediat solicitate, de obicei, pe aceeași conexiune la care a venit cererea. Dacă mesajul cu msg_id lipsă sau solicitate au fost uitate, sau dacă este trimisă părții solicitante (care este de înțeles de paritate) pentru un astfel de răspuns este trimis msg_id MsgsStateInfo.