протоколы двоичной синхронной передачи данных v. текстовых протоколов

Я думаю, вы ошиблись. Внешний вид данных на экране определяется не протоколом. "провод", но именно тип данных определяет, какой протокол использовать для его передачи. Возьмем, к примеру, сокет tcp, файл jpeg будет отправлен и получен с помощью двоичного протокола, потому что это двоичные данные (не человеческие читаемые байты, которые попадают в диапазон 32-126 ascii), но вы можете отправить / получить текстовый файл с обоими протоколами, и вы не заметите разницы.

Примеры двоичных протоколов: RTP , TCP , IP .

Примеры текстовых протоколов: SMTP , HTTP , SIP .

Это должно позволить вам обобщить разумное определение двоичных и текстовых протоколов.

Совет: просто перейдите к разделам с примерами или диаграммам. Они служат для иллюстрации потрясающего ответа Тайлера .

Оба используют разные наборы символов, текстовый, используют сокращенный набор символов, двоичный файл включает все, что может, а не только «буквы» и «числа» (поэтому в Википедии написано «человек»)

o будьте более ясны, если у меня есть файл jpg, как он будет отправлен через двоичный протокол и как> через текстовый? с точки зрения бит / байтов, отправленных по сети, конечно.

вы должны прочитать это Base64

любые комментарии приветствуются, я пытаюсь добраться до сути вещей здесь.

Я думаю, что суть сужения кодировки заключается в сужении сложности и достижении переносимости, совместимости. Труднее организовать и согласиться со многими уважать широкую кодировку (или что-то еще). Латинский / латинский алфавит и арабские цифры известны во всем мире. (Конечно, есть и другие соображения по сокращению кода, но это главный)

Допустим, в бинарных протоколах «контракт» между частями касается битов, первый бит означает то, второй то и т. Д. Или даже байтов (но со свободой использования кодировки, не думая о переносимости), например, в закрытой закрытой системе или (рядом со стандартами оборудования), однако, если вы разрабатываете открытую систему, вы должны учитывать, как ваши коды будут представлены в широком наборе ситуаций, например, как он будет представлен в машине на другой стороне мира ?, поэтому здесь идут текстовые протоколы, в которых контракт будет максимально стандартным. Я разработал и то, и другое, и это было причиной: двоичный код для очень нестандартных решений и текст для открытых и / или переносимых систем.

Как большинство из вас предположили, мы не можем различить, является ли протокол двоичным или текстовым, просто глядя на содержимое в сети

AFIK

Бинарный протокол - Биты являются граничными Порядок очень важен

Например, RTP

Первые два бита - версия Следующий бит - это бит MarkUp

Текстовый протокол - разделители, специфичные для протокола. Порядок полей не важен

Например, SIP

Еще одно: в двоичном протоколе мы можем разделить байт, то есть отдельный бит может иметь определенное индивидуальное значение; В текстовом протоколе минимальная значимая единица - БАЙТ. Вы не можете разбить байт.

Вот такое отговорочное определение:

Вы узнаете это, когда увидите.

Это один из тех случаев, когда очень трудно найти краткое определение, охватывающее все крайние случаи. Но это также и один из тех случаев, когда угловые случаи совершенно неуместны, потому что в реальной жизни их просто не бывает.

Практически все протоколы, с которыми вы столкнетесь в реальной жизни, будут выглядеть так:

> fg,m4wr76389b zhjsfg gsidf7t5e89wriuotu nbsdfgizs89567sfghlkf
>  b9er t8ß03q+459tw4t3490ß´5´3w459t srt üßodfasdfäasefsadfaüdfzjhzuk78987342
< mvclkdsfu93q45324äö53q4lötüpq34tasä#etr0 awe+s byf eart

[Представьте себе кучу другой непечатаемой чепухи. Одна из сложностей в передаче разницы между текстом и двоичным файлом заключается в том, что вам нужно сделать это в тексте :-)]

Или вот так:

< HELLO server.example.com
> HELLO client.example.com
< GO
> GETFILE /foo.jpg
< Length: 3726
< Type: image/jpeg
< READY?
> GO
< ... server sends 3726 bytes of binary data ...
> ACK
> BYE

[Я просто придумал это на месте.]

Там просто не так уж много двусмысленности.

Еще одно определение, которое я иногда слышал:

текстовый протокол — это протокол, который можно отлаживать с помощью telnet

Возможно, здесь я показываю свою занудство, но я на самом деле написал и читал электронную почту через SMTP и POP3, читал статьи Usenet через NNTP и просматривал веб-страницы через HTTP, используя telnet, только для того, чтобы посмотреть, будет ли это работать на самом деле.

Вообще-то, когда я писал это, меня опять словно лихорадило:

bash-4.0$ telnet smtp.googlemail.com 25
Trying 74.125.77.16...
Connected to googlemail-smtp.l.google.com.
Escape character is '^]'.
< 220 googlemail-smtp.l.google.com ESMTP Thu, 15 Apr 2010 19:19:39 +0200
> HELO
< 501 Syntactically invalid HELO argument(s)
> HELO client.example.com
< 250 googlemail-smtp.l.google.com Hello client.example.com [666.666.666.666]
> RCPT TO:Me <Me@Example.Com>
< 503 sender not yet given
> SENDER:Me <Me@Example.Com>
< 500 unrecognized command
> RCPT FROM:Me <Me@Example.Com>
< 500 unrecognized command
> FROM:Me <Me@Example.Com>
< 500-unrecognized command
> HELP
< 214-Commands supported:
< 214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN
> MAIL FROM:Me <Me@Example.Com>
< 250 OK
> RCPT TO:You <You@SomewhereElse.Example.Com>
< 250 Accepted
> DATA
< 354 Enter message, ending with "." on a line by itself
> From: Me <Me@Example.Com>
> To: You <You@SomewhereElse.Example.Com>
> Subject: Testmail
>
> This is a test.
> .
< 250 OK id=1O2Sjq-0000c4-Qv
> QUIT
< 221 googlemail-smtp.l.google.com closing connection
Connection closed by foreign host.

Блин, давненько я этого не делал. Там довольно много ошибок :-)