OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 15 Декабрь, 2019 12:47

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 26 Октябрь, 2009 12:35 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1215
В файл писать по одному байту тоже не очень эффективно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 26 Октябрь, 2009 12:51 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Сергей Губанов писал(а):
Не надо над TCP делать read/write мапперы навроде Stores.Reader/Writer. Это просто не эффективно, например, если выполнено два вызова WriteByte, то значит по сети надо переслать 1 байт, а потом переслать ещё 1 байт? Нет, здесь паттерн carrier-rider-mapper не применим.
Ну, мне казалось, про что такое буфер знает каждый программер :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 26 Октябрь, 2009 12:52 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Trurl писал(а):
В файл писать по одному байту тоже не очень эффективно.
Ув. Trurl меня опередил своим намёком.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 26 Октябрь, 2009 22:44 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Info21 писал(а):
Сделайте аналог Stores.Writer|Reader над TCP.
(Давно уж пора сделать бы ...)
+
Info21 писал(а):
Ну, мне казалось, про что такое буфер знает каждый программер :)
Так над чем предлагается сделать маппер: над буфером или над сетевым интерфейсом?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 00:06 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Сергей Губанов писал(а):
Так над чем предлагается сделать маппер: над буфером или над сетевым интерфейсом?
Буфер -- это деталь реализации маппера над сетевым интерфейсом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 09:07 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Вы говорили о CommStreams.Stream и маппере навроде Stores.Reader/Writer.

Маппер а-ля Stores.Reader/Writer возможен над буфером, но невозможен над CommStreams.Stream.

Простой пример. Задумайтесь как реализовать над CommStreams.Stream.ReadBytes процедуру Stores.Reader.ReadReal. Процедуре ReadReal нужны восемь байтов, но на момент её вызова по сети может быть получено меньшее количество байтов. Каково должно быть её поведение в этом случае? По ассерту завалить программу?

Чтобы не ломать голову, десериализации логично подвергать целое сообщение.

Поэтому поверх сетевого интерфейса (CommStreams.Stream) надо реализовать другой интерфейс -- специального транспортного протокола уже для целых сообщений. Этот протокол обеспечивает транспортировку неделимых массивов байтов. Зная только их размер он не знает как их десериализовывать.

Далее (в стеке протоколов) выстраивается ещё один уровень абстракции -- объектный. Этот интерфейс заведует сериализацией и десериализацией объектов в массивы байтов и обратно. На входе у него очередь отправляемых объектов, на выходе -- очередь доставленных объектов.

Маппер а-ля Stores.Reader/Writer засунут в механизм сериализации/десериализации этого последнего объектного интерфейса (и реализован этот маппер над буфером).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 10:41 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8215
Откуда: Троицк, Москва
Сергей Губанов писал(а):
Вы говорили ...
Да я не против. В контексте моего высказывания это всё детали реализации. Семечки для столь крутых мастеров :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 12:33 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Вопрос к .NET-щикам: а там какая-то абстракция для потокового ввода-вывода путёвая сделана?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 12:39 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1215
Сергей Губанов писал(а):
Чтобы не ломать голову, десериализации логично подвергать целое сообщение.

Это только переносит проблему в другое место.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 13:02 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Есть ли какие-то смысловые нюансы в терминах stream, channel, pipe - или выбор любого из них - дело вкуса?

О. Есть ещё: link

О. Channel, оказывается, применяется для односторонних каналов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 14:20 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Вопрос к .NET-щикам: а там какая-то абстракция для потокового ввода-вывода путёвая сделана?

Ну в принципе есть классы StreamReader/StreamWriter, которые используются для записи/чтения файлов, связи через TCPClient/TCPServer и прочего.
В общем-то вроде работает, и даже вполне юзабельно (ну хотя тут на разные вкусы не угодишь, конечно).
Правда, сериализация/десериализация данных в бинарный вид по моим тестам оказалась медленнее, чем работа с plain text-файлами, страшно представить, как тормознуто будет это с XML-сериализацией работать...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 14:28 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Есть ли какие-то смысловые нюансы в терминах stream, channel, pipe - или выбор любого из них - дело вкуса?

stream -- поток для работы с файлами в основном, а также для эмуляции ленивых списков (потоки данных) в энергичных языках.

channel -- для связи между процессами, работает как очередь, накапливающая сообщения.

pipe -- конвейер из программ: одна отработала, выдала данные для другой, та для третьей и т.д.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 14:44 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Меня интересует не то, для чего используется в языках/ОС; а нюансы самих слов. В технике.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Октябрь, 2009 15:30 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Тогда примерно так:
Stream обозначает процесс движения.
Channel задаёт направление движения.
Pipe - механизм объединения (согласования) Channel для формирования единого пути, который на уровне выше, где pipe не виден, выглядит (или может выглядеть) как Channel.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Октябрь, 2009 11:13 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Илья Ермаков писал(а):
Вопрос к .NET-щикам: а там какая-то абстракция для потокового ввода-вывода путёвая сделана?
Ну там есть как бы универсальная "царь-машина" System.IO.Stream с кучей наследников. Я ей не пользуюсь, написал своё конкретное (в смысле не универсальное).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Октябрь, 2009 19:32 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Что-то я такое смотрел... Там полная хреновня с перегрузкой вывода разных типов? Как С++-потоки?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 31 Октябрь, 2009 18:02 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Там полная хреновня с перегрузкой вывода разных типов? Как С++-потоки?
Такой обескураживающий вопрос...
Что значит -- "полная хреновня"?
А как Вы-то хотели? Так же как у Вас в Блекбоксе -- для каждого типа отдельная процедура? Да нафик надо...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 31 Октябрь, 2009 18:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Это два разных слоя по определению - нетипизированный поток и мэппинг типов в байты.
(Например, сколько разных способов вывести текст? В какой кодировке? И т.п.)

Или у Шарпа-Явы проблемы с работой с нетипизированными данными? Приходится прошивать маппинг на самый нижний уровень, в "методы" элементарных типов? Ну так это родовые проблемы, заложенные в язык.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 31 Октябрь, 2009 21:05 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Или у Шарпа-Явы проблемы с работой с нетипизированными данными?

Какая может быть вменяемая работа с нетипизированными данными? Проблемы с ними быть обязаны, ибо нефиг заниматься такими вещами, не BCPL всё-таки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 31 Октябрь, 2009 21:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9165
Откуда: Россия, Орёл
Представьте себе, очень даже может быть :)

А если я Вам скажу, что может быть ещё и безопасной, Вы вообще в осадок выпадете? :)

(понимая под безопасностью, например, в КП - неиспользование SYSTEM или аналогичных средств, могущих нарушить целостность памяти).

Подсказка: сочетание абстракции типа Files.File (двоичный байтовый поток), метапрограммирования и наличия в языке нормальных нединамических структур данных.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB