18. april 2002 - 20:36Der er
5 kommentarer og 2 løsninger
Data terminator i egen netværksprotokol?
Hvis jeg holder en socket åben til kommunikation frem og tilbage, hvordan ved jeg så hvornår f.eks. min server er færdig med at sende en fil til min klient?
F.eks. i POP3 RFC1939 skriver de følgende: [SNIP] Responses to certain commands are multi-line. In these cases, which are clearly indicated below, after sending the first line of the response and a CRLF, any additional lines are sent, each terminated by a CRLF pair. When all lines of the response have been sent, a final line is sent, consisting of a termination octet (decimal code 046, ".") and a CRLF pair. If any line of the multi-line response begins with the termination octet, the line is "byte-stuffed" by pre-pending the termination octet to that line of the response. Hence a multi-line response is terminated with the five octets "CRLF.CRLF". When examining a multi-line response, the client checks to see if the line begins with the termination octet. If so and if octets other than CRLF follow, the first octet of the line (the termination octet) is stripped away. If so and if CRLF immediately follows the termination character, then the response from the POP server is ended and the line containing ".CRLF" is not considered part of the multi-line response. [/SNIP]
Men jeg kan ikke helt forstå hvorda det kan virke. Hvad hvis de transmitterede data indeholder "CRLF.CRLF", hvad så?
Er der en der kan forklarer mig hvordan jeg kan være helt sikker på at min transmission er færdig, please?
Når der kommer CRLF.CRLF er den færdig, hvis der kommer CRLF.x (Hvor x er alt andet end CRLF), er den ikke færdig endnu. Husk at strippe .CRLF fra din message.
Ok - så det er op til sendere :) Desværre duer det ikke i mit tilfælde så, da det er filer jeg sender over min socket, og det kan være alt mulig data (binær), så dem kan jeg ikke pille ved.
Standard for mail er at encode til base64, ie 6 signifikante bits (pr byte), og så decode på modtagersiden. Det er dog ikke særlig optimalt, hvis det drejer sig om større filer. De fylder jo noget mere. Men hvis du laver en CRLF.CRLF slutning og så derpå lægger en afslutningskommando eller en id for forsendelsen ie: sender: data.... sender: crlf.crlf sender: transfer id: et-eller-andet finished (hvor du også har sendt id før forsendelsen, burde det lade sig gøre at undgå tilfældigheder. Hvis dit id er stærkt nok.
I henhold til dit spørgsmål for oven vil jeg lige nævne, at base64 ikke giver mulighed for CRLF.CRLF... Og denne metode bruges selvfølgelig primært med MimeType bodyparts der er forskellige fra tekst, også kaldet attachments.
jword vil du ikke lige svare i stedet for at kommenterer, jeg syntes at I tilsammen har svaret meget godt, så en deling af points er vist på sin plads her.
Har I evt. et forslag til hvordan jeg fanger mit transfer id? Jeg bliver vel nød til at implementerer en eller anden for for "look afhead" feature, men hvordan gør jeg nu det? Hvis jeg f.eks. fanger et CR, så vil jeg læse næste tegn (som sikkert er LF), så læser jeg næste tegn igen og hvis det ikke er . så vil jeg videre, osv. Men hvad så??? Jeg bliver nød til at læse det tegn for tegn, og følgende strng vil splitte min algoritme ad "CRLFCRLF.CRLF" fordi at min aloritme fanger CR læser det næste som er LF og det næste som er CR, og så springer den videre for det var ikke hvad den forventede, men i næste runde læser den . først, og da det ikke er CR springer den straks videre... :(
Nogle gode ideer? Jeg giver gerne points for et godt svar :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
