Мучающий меня 10 лет вопрос

[metaclass]

Люди, а скажите мне - через | (пайп) БИНАРНЫЕ данные проходят?
Особо интересует - на линуксе и на винде. Про первое я знаю, что проходят, т.к. arecord | aplay работает, а вот про второе уже 10 лет мучаюсь, но никак руки не дойдут проверить :)

Comments

[nicka-startcev.livejournal.com]

а что значит "в потоке данные закончились"?
Вот, например, есть у нас "компорт", пришел из него байт. Через 1мс еще байт, потом через 2,4,8,16,32...стопицот итд мс еще по байту. В какой момент будем считать, что поток закончился?

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

[trueblacker.livejournal.com]

>По уму, устройство должно явно сказать, что данных больше нет

вот и вы и сформулировали причину, по которой EOF удобен

[nicka-startcev.livejournal.com]

в байтовом потоке выделить как минимум два байта для служебных целей? Как-то некамильфо.

почему два -- а опишите как вы будете передавать тот байт, у которого код совпадает с тем, который мы назначили ЕОФ.

[trueblacker.livejournal.com]

я не собираюсь утверждать, что EOF - это тру и так всем надо делать.
Я протестую против того, что в нём не было логики и смысла изначально. В те времена данные в файлы вводились с клавиатуры, а не снимались говнозеркалками. Поэтому такая экзотика как EOF вполне могла решать задачу сигнализирования о конце передаваемого файла.

[ex0_planet]

вы путаете уровни
по уму это делается передачей по физическому уровню запрещенного символа, который не конвертируется в канальные символы.
ну или можно in-band в канале, специальной комбинацией, но тогда эскейпинг должен быть предусмотрен.

[trueblacker.livejournal.com]

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

Да, если ставить задачу разработки протокола, позволяющего передавать ЛЮБЫЕ байты, нужно изобретать ухищрения вроде "канал данных/канал контроля", "канальный/транспортный/физический уровень", "протокол с ескейпингом" и пр.

Если же говорить о передаче "обычного текста" (т.е. весьма ограниченного подмножества ASCII), которая в своё время составляла, подозреваю, более 83% всех передач, задача решается на порядок проще - введением управляющих символов.

[ex0_planet]

В общем, телефонисты (точнее телеграфисты) как всегда во всем виноваты. У них цеховая традиция - делать решения феерической кривожопости, с которыми остальным сорок лет приходится как-то мириться.

"Такие странные значения" не берутся все же из ниоткуда, а вытекают из устройства кодовой таблицы. Просто кем-то когда-то было принято решение о том, что ничего кроме латинских букв и цифр никому никогда передавать не потребуется - и вот это и есть настоящая кривость, под которую и придумали кодовую таблицу.

Эскейпинг в данном случае делается проще некуда: один, условно говоря, "компаратор" и один триггер, который даже механически реализовать не проблема. Зато потом не нужно было бы изобретать ANSI-эскейпинг, кодировки, line discipline и прочую хрень...

[trueblacker.livejournal.com]

>Просто кем-то когда-то было принято решение о том, что ничего кроме латинских букв и цифр никому никогда передавать не потребуется

это было сделано человечеством, которое сформировало язык естественного общения таким, какой он есть - 26 букв плюс пунктуационные мелочи.

То, что информационная эра вносит в традиции свои правки было осознанно позже.

[ex0_planet]

Как бе о том, что текст - это не просто последовательность буков было известно сильно заранее. Просто в то, чем можно было пользоваться исключительно для телеграфа, попытались запихнуть элементы верстки, управления линком и черт знает что еще, вместо того чтобы сесть и сделать по нормальному.

Подозреваю, кстати, что там тоже участвовали адепты мифической "обратной совместимости на бинарном уровне".