SyncStream — библиотека C# для передачи данных по нестабильным каналам

[sse]

Такой вопрос — на чем тестировали?

[hardex]

На TCP, с периодическим закидыванием мусора в канал

[o_O_Tync]

Такой ламерский вопрос: а почему синхронизации и защиты от потерь самого TCP/IP недостаточно для работы через нестабильные каналы? Может, было бы достаточно лишь увеличить таймаут своего сокета?

[hardex]

Потому что библиотека работает не только на TCP/IP но на вообще любом канале по выбору — например, через какой-нибудь внешний девайс, будь то IR, радио или еще что-нибудь — достаточно написать и подцепить нужный класс.
Короче, канал != ethernet

[kmike]

Вы ответили не на тот вопрос, который был задан)

Переформулирую. Что мешает запустить TCP (или какой-то другой протокол с гарантированной доставкой) поверх любого другого канала?

Если вы разработали еще один протокол с гарантированной доставкой, то

а) зачем еще один нестандартный протокол, если есть стандартные?

б) зачем пускать протокол с гарантированной доставкой поверх другого протокола с гарантированной доставкой?

[hardex]

Эм… возможно, я просто не в теме, но:
Как запустить TCP/IP поверх IR адаптера последовательного порта?

[kmike]

Как это делается конкретно и на C# — без понятия, но возможность выйти в интернет с КПК через телефон, подцепленный через инфракрасный порт, является наглядным примером, что это вполне себе обычная практика.

[hardex]

Для этого производителем пишутся драйвера, которые обеспечивают определение телефона как сетевого адаптера (аналогично работает GPRS через телефон на ноутбук)

[kmike]

Ок, в этом случае появляется еще доп. слой абстракции. Но, во-первых, это не отменяет того факта, что TCP/IP спокойно себе идет через ИК-порт. Драйвер — это ж не магия какая-то, это обычный вполне код. Во-вторых, реально у нас есть схема:

физ. интерфейс — [какой-то код] — программный интерфейс

и технически ничто не мешает предоставить TCP-интерфейс вместо интерфейса сетевого адаптера. Мешает только то, что у нас получится несколько TCP-интерфейсов в системе и потребуется модификация программ, чтоб использовать нестандартный. Но у вас, по сути, и так модификация программ.

Да и вообще, как это все к делу относится-то. Если вы в принципе не согласны с тем, что TCP/IP не завязан на канал и его можно пустить поверх любого канала, то почитайте хотя бы основы про OSI.

[hardex]

С тем, что TCP/IP не завязан на канал я абсолютно согласен, и с моделью OSI ознакомлен (:
Просто писать драйвера не так-то и просто (:

[kmike]

Не нужно писать драйвер) Драйвер тут пишется только для того, чтобы код других программ менять не нужно было, чтоб была одна точка входа, грубо говоря.

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

[kmike]

Да, я не призываю реализовывать-использовать обязательно TCP/IP. Есть и другие протоколы.

Просто показалось, что тут началось написание велосипеда без исследования плюсов и минусов существующих (уже много лет) решений, а это не есть хорошее начало для велосипеда)

[icoder]

TCP/IP работает не то что поверх IR адаптера но и даже поверх голубиной почты, на что существует свой отдельный RFC за номером 1149: tools.ietf.org/html/rfc1149

[hardex]

Здесь я хотел услышать конкретное описание поднятия tcp на конкретном устройстве — трудоемкость, нужное время, ПО и т.п.

[serbod]

TCP/IP это протокол сеансового уровня, а не канального.

[kmike]

Ну если придираться, то по OSI это 2 протокола, сетевого и транспортного уровня)
Правда сути дела это совершенно не меняет)

[hardex]

Как пример — собрать из фотодиодов и лазерных указок модули Tx/Rx и подключить через COM-порты, сделать класс, который будет направлять ввод-вывод на этот порт и получаем оптический канал

[hardex]

Если бы вы внимательно прочитали описание, то, возможно, увидели бы, что библиотека вообще не привязана к TCP/IP

[awhiler]

Гарантированна ли очередность доставки пакетов?
Гарантированно ли то, что каждый пакет будет доставлен только один и только один раз?

Терзают меня смутные сомнения, что, так как в загловке пакет нет никакого id, то нет.

Вообще WCF тоже позволяет прикрутить любой транспорт, и использовать при этом уже реализованный relaible messaging. Я бы наверно делал так.

[pieceofsummer]

я бы тоже делал через wcf, особенно после заглядывания в исходник :)

[hardex]

Гарантированна ли очередность доставки пакетов?

Нет.

Гарантированно ли то, что каждый пакет будет доставлен только один и только один раз?

Да. Для пакетов с гарантированной доставкой (которые могут быть отправлены повторно) добавляется аргумент «x-packet-uid», который и содержит уникальный ID.

[pieceofsummer]

Из названия библиотеки ни разу не понятно, что речь идет о нестабильных каналах — скорее о thread-safe потоках данных

[Pilat]

Я не могу понять вот чего. Вы пишете, что используете TCP протокол — но он же уже обеспечивает доставку. Как мне кажется, такие системы надо писать на UDP. При этом ещё одна задача ускользнула, похоже, от Вашего внимания — увеличение скорости передачи, на глючных каналах это возможно и очень существенно.

[hardex]

Перечитайте пост еще раз, пожалуйста…

[Pilat]

Я не понимаю…

[hardex]

Библиотека ни коим образом не привязана к TCP/IP

[Kndy]

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

[serbod]

Выглядит попроще, чем ZModem и тем более Hydra или Janus.

Замечания:
* CRC подлинней (1 байт IMHO, маловато)
* не мешал бы код Хаффмана для восстановления «битых» пакетов
* динамическая длина пакетов (в зависисмости от частоты ошибок)
* перезапросы «битых» пакетов без остановки потока

[hardex]

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

[serbod]

Если слишком часто пакеты приходят битые, то размер передаваемых пакетов автоматически уменьшается. Это повышает вероятность успешной передачи пакета ценой некоторого оверхеда на заголовках. И уменьшает объем «теряемой» информации при повторах.

[hardex]

Насколько я понимаю, это применимо к поточной передаче данных, а здесь пакеты формируются непосредственно отправителем

[serbod]

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

[hardex]

Я имею в виду, что пакеты здесь нельзя взять, разделить пополам и отправить части отдельно

[serbod]

А как же быть, если мы пытаемся передать картинку пакетом в 500 КБайт, а он каждый раз битый приходит? А если его «нарезать» по 1-2-4-8-16 КБайт, то он нормально передастся, будет потеряно только 20-50 КБайт на повторах и оверхеде.

[serbod]

Прошу прощения, для коррекции ошибок используется код Хемминга

[pwlnw]

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