Comments 38
Такой вопрос — на чем тестировали?
0
Такой ламерский вопрос: а почему синхронизации и защиты от потерь самого TCP/IP недостаточно для работы через нестабильные каналы? Может, было бы достаточно лишь увеличить таймаут своего сокета?
+3
Потому что библиотека работает не только на TCP/IP но на вообще любом канале по выбору — например, через какой-нибудь внешний девайс, будь то IR, радио или еще что-нибудь — достаточно написать и подцепить нужный класс.
Короче, канал != ethernet
Короче, канал != ethernet
-1
Вы ответили не на тот вопрос, который был задан)
Переформулирую. Что мешает запустить TCP (или какой-то другой протокол с гарантированной доставкой) поверх любого другого канала?
Если вы разработали еще один протокол с гарантированной доставкой, то
а) зачем еще один нестандартный протокол, если есть стандартные?
б) зачем пускать протокол с гарантированной доставкой поверх другого протокола с гарантированной доставкой?
Переформулирую. Что мешает запустить TCP (или какой-то другой протокол с гарантированной доставкой) поверх любого другого канала?
Если вы разработали еще один протокол с гарантированной доставкой, то
а) зачем еще один нестандартный протокол, если есть стандартные?
б) зачем пускать протокол с гарантированной доставкой поверх другого протокола с гарантированной доставкой?
+3
Эм… возможно, я просто не в теме, но:
Как запустить TCP/IP поверх IR адаптера последовательного порта?
Как запустить TCP/IP поверх IR адаптера последовательного порта?
-1
Как это делается конкретно и на C# — без понятия, но возможность выйти в интернет с КПК через телефон, подцепленный через инфракрасный порт, является наглядным примером, что это вполне себе обычная практика.
0
Для этого производителем пишутся драйвера, которые обеспечивают определение телефона как сетевого адаптера (аналогично работает GPRS через телефон на ноутбук)
-1
Ок, в этом случае появляется еще доп. слой абстракции. Но, во-первых, это не отменяет того факта, что TCP/IP спокойно себе идет через ИК-порт. Драйвер — это ж не магия какая-то, это обычный вполне код. Во-вторых, реально у нас есть схема:
физ. интерфейс — [какой-то код] — программный интерфейс
и технически ничто не мешает предоставить TCP-интерфейс вместо интерфейса сетевого адаптера. Мешает только то, что у нас получится несколько TCP-интерфейсов в системе и потребуется модификация программ, чтоб использовать нестандартный. Но у вас, по сути, и так модификация программ.
Да и вообще, как это все к делу относится-то. Если вы в принципе не согласны с тем, что TCP/IP не завязан на канал и его можно пустить поверх любого канала, то почитайте хотя бы основы про OSI.
физ. интерфейс — [какой-то код] — программный интерфейс
и технически ничто не мешает предоставить TCP-интерфейс вместо интерфейса сетевого адаптера. Мешает только то, что у нас получится несколько TCP-интерфейсов в системе и потребуется модификация программ, чтоб использовать нестандартный. Но у вас, по сути, и так модификация программ.
Да и вообще, как это все к делу относится-то. Если вы в принципе не согласны с тем, что TCP/IP не завязан на канал и его можно пустить поверх любого канала, то почитайте хотя бы основы про OSI.
+1
С тем, что TCP/IP не завязан на канал я абсолютно согласен, и с моделью OSI ознакомлен (:
Просто писать драйвера не так-то и просто (:
Просто писать драйвера не так-то и просто (:
-1
Не нужно писать драйвер) Драйвер тут пишется только для того, чтобы код других программ менять не нужно было, чтоб была одна точка входа, грубо говоря.
У вас же и так уже библиотека, значит подразумевается доступ к исходному коду прикладной программы, значит никакой драйвер не нужен.
У вас же и так уже библиотека, значит подразумевается доступ к исходному коду прикладной программы, значит никакой драйвер не нужен.
0
Да, я не призываю реализовывать-использовать обязательно TCP/IP. Есть и другие протоколы.
Просто показалось, что тут началось написание велосипеда без исследования плюсов и минусов существующих (уже много лет) решений, а это не есть хорошее начало для велосипеда)
Просто показалось, что тут началось написание велосипеда без исследования плюсов и минусов существующих (уже много лет) решений, а это не есть хорошее начало для велосипеда)
0
TCP/IP работает не то что поверх IR адаптера но и даже поверх голубиной почты, на что существует свой отдельный RFC за номером 1149: tools.ietf.org/html/rfc1149
+1
TCP/IP это протокол сеансового уровня, а не канального.
0
Как пример — собрать из фотодиодов и лазерных указок модули Tx/Rx и подключить через COM-порты, сделать класс, который будет направлять ввод-вывод на этот порт и получаем оптический канал
+1
UFO just landed and posted this here
Гарантированна ли очередность доставки пакетов?
Гарантированно ли то, что каждый пакет будет доставлен только один и только один раз?
Терзают меня смутные сомнения, что, так как в загловке пакет нет никакого id, то нет.
Вообще WCF тоже позволяет прикрутить любой транспорт, и использовать при этом уже реализованный relaible messaging. Я бы наверно делал так.
Гарантированно ли то, что каждый пакет будет доставлен только один и только один раз?
Терзают меня смутные сомнения, что, так как в загловке пакет нет никакого id, то нет.
Вообще WCF тоже позволяет прикрутить любой транспорт, и использовать при этом уже реализованный relaible messaging. Я бы наверно делал так.
+2
я бы тоже делал через wcf, особенно после заглядывания в исходник :)
0
Гарантированна ли очередность доставки пакетов?
Нет.
Гарантированно ли то, что каждый пакет будет доставлен только один и только один раз?
Да. Для пакетов с гарантированной доставкой (которые могут быть отправлены повторно) добавляется аргумент «x-packet-uid», который и содержит уникальный ID.
-1
Из названия библиотеки ни разу не понятно, что речь идет о нестабильных каналах — скорее о thread-safe потоках данных
0
Я не могу понять вот чего. Вы пишете, что используете TCP протокол — но он же уже обеспечивает доставку. Как мне кажется, такие системы надо писать на UDP. При этом ещё одна задача ускользнула, похоже, от Вашего внимания — увеличение скорости передачи, на глючных каналах это возможно и очень существенно.
0
Помимо всего прочего уже сказанного, в порядке бреда, провести верификацию сетевого протокола, даже если учитывать, что он является надстройкой над транспортным уже верифицированным. Тов. awhiler, кстати, важные вопросы задал, особенно про нумерацию пакетов и их склеивание по приходу.
0
Выглядит попроще, чем ZModem и тем более Hydra или Janus.
Замечания:
* CRC подлинней (1 байт IMHO, маловато)
* не мешал бы код Хаффмана для восстановления «битых» пакетов
* динамическая длина пакетов (в зависисмости от частоты ошибок)
* перезапросы «битых» пакетов без остановки потока
Замечания:
* CRC подлинней (1 байт IMHO, маловато)
* не мешал бы код Хаффмана для восстановления «битых» пакетов
* динамическая длина пакетов (в зависисмости от частоты ошибок)
* перезапросы «битых» пакетов без остановки потока
+1
Можете пояснить третий пункт?
Насчет перезапросов, сейчас важные пакеты автоматически перепосылаются, если нет подтверждения о получении до таймаута, все без остановки потока.
Насчет перезапросов, сейчас важные пакеты автоматически перепосылаются, если нет подтверждения о получении до таймаута, все без остановки потока.
-1
Если слишком часто пакеты приходят битые, то размер передаваемых пакетов автоматически уменьшается. Это повышает вероятность успешной передачи пакета ценой некоторого оверхеда на заголовках. И уменьшает объем «теряемой» информации при повторах.
0
Насколько я понимаю, это применимо к поточной передаче данных, а здесь пакеты формируются непосредственно отправителем
-1
Это применимо к любому пакетному способу передачи данных с обратной связью.
0
Я имею в виду, что пакеты здесь нельзя взять, разделить пополам и отправить части отдельно
-1
Прошу прощения, для коррекции ошибок используется код Хемминга
+1
Пример безудержной программистской тяги к обобщению. Только вот если IP есть везде, где можно передавать данные. Какой тогда практический смысл в этом?
0
Sign up to leave a comment.
SyncStream — библиотека C# для передачи данных по нестабильным каналам