Jump to content

    
sigmaN

Посоветуйте что почитать по реализации протоколов

Recommended Posts

1 hour ago, mantech said:

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

C протоколами чаще всего проблема в неопределенности угроз. 
Если вы не имеете серьезных помех по RS485 и не имеет жестких требований по времени доставки, то можете там писать поверх него все что вздумается.
И все  равно оно будет работать. 

А вот с модемными протоколами типа PPP или многоканальными типа TCP или mesh протоколами все гораздо сложнее.
И не напишите вы их ни за 3 недели ни за год. Потому что они требуют адекватного моделирования, а адекватная модель требует исследования среды передачи и изучение мат. аппарата. 

Share this post


Link to post
Share on other sites
2 часа назад, AlexandrY сказал:

Если вы не имеете серьезных помех по RS485 и не имеет жестких требований по времени доставки,

Если б это было так, то и заморачиваться бы не стал, кинул несколько каналов точка-точка на 232м с гальваноразвязкой, да и делов-то... Как раз использование предполагает наличие помех и управление силовыми нагрузками, средняя задержка вкл\выкл канала не более 10мсек, считывание данных с датчиков обратной связи. Поэтому только мастер-слейв, только минимальные таймслоты для пакетов автодетекта, без всякой анархии навроде csma-cd и пр.

Edited by mantech

Share this post


Link to post
Share on other sites
5 часов назад, Ruslan1 сказал:

Например, про легкий вариант lwip: нужна действительно очень специальная ниша, если его модульности, доступной через систему дефайнов, не хватает.

Очень специальная?  :russian_ru:  Ну например - требование минимального расхода ОЗУ (так как её дефицит) для нескольких одновременно открытых сокетов - очень специально? Позволяет ли lwIP организовать работу с TCP-сокетами так, чтобы вообще не требовался бы буфер для TCP-сокета? И чтобы, при этом, скорость работы такого сокета не упала ниже плинтуса.

Если это уже - "специальные требования", то тогда у меня все проекты - только "специальные ниши".  :wink2:

Share this post


Link to post
Share on other sites
1 hour ago, jcxz said:

Очень специальная?  :russian_ru:  Ну например - требование минимального расхода ОЗУ (так как её дефицит) для нескольких одновременно открытых сокетов - очень специально? Позволяет ли lwIP организовать работу с TCP-сокетами так, чтобы вообще не требовался бы буфер для TCP-сокета? И чтобы, при этом, скорость работы такого сокета не упала ниже плинтуса.

Если это уже - "специальные требования", то тогда у меня все проекты - только "специальные ниши".  :wink2:

Ага. Хороший пример. Да, я считаю что это именно тот особый случай: применен протокол, под буфер которого не предусмотрено аппаратных ресурсов. Тут надо извиваться ужом (между ресурсами и производительностью), и это необычно.

Сейчас ресурсы сильно дешевле чем рабочее время, так что практически всегда рентабельней иначе решать, без выкручивания рук разработчику. Обратная ситуация, конечно, бывает, но лично я с таким давно не сталкивался. История одного байта- это уже давнее прошлое.

Share this post


Link to post
Share on other sites
11 минут назад, Ruslan1 сказал:

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

Это пока вы не сталкиваетесь с разработкой серийных изделий со сколько-нибудь значительной серией. И тогда уже вам будут выкручивать руки снабженцы и отдел продаж. Чтобы впихнуть побольше в МК подешевле.

Или когда надо добавить какой-то функционал в уже готовое изделие, где ресурсы на исходе.

Да и в начале разработки, даже если серия не грозит, всегда есть смысл экономить ресурсы. Чтобы потом, если вдруг окажется, что нужно ещё пару программных фич впихнуть, не пришлось весь проект переделывать с нуля.

А ещё бывает что выбора просто нет, так как есть другие требования: исполнение, температурный диапазон, наличие какой-то периферии и пр. И выбор подходящих МК - раз, два и обчёлся. И тогда работаешь с тем, что есть.

Цитата

Обратная ситуация, конечно, бывает, но лично я с таким давно не сталкивался. История одного байта- это уже давнее прошлое.

Где-ж давняя? Разница в ценах между жирными МК и более простыми никуда не делась и сейчас.

Share this post


Link to post
Share on other sites
45 minutes ago, jcxz said:

Это пока вы не сталкиваетесь с разработкой серийных изделий со сколько-нибудь значительной серией. И тогда уже вам будут выкручивать руки снабженцы и отдел продаж. Чтобы впихнуть побольше в МК подешевле.

Абсолютно согласен. Я догадываюсь что такое масс-продакшн и понимаю, что там подходы другие. Если Вы именно там крутитесь и выживаете- то честь Вам и хвала. Серьезно, без сарказма. Я б наверное уже не смог.

Когда-то каждый дизайн делал, как будто завтра миллион выпустим и сэкономим на этом аж миллион денег. Но потом прошло. Будет такой тираж- тоже буду байты считать, даташиты с китайского переводить и про массу затраченного припоя думать.

Share this post


Link to post
Share on other sites

Начали за здравие, как говорится.....

Изначально был вопрос о реализации протоколов, которые уже разработаны и все мат.модели выверены.

Share this post


Link to post
Share on other sites
14 minutes ago, sigmaN said:

Изначально был вопрос о реализации протоколов, которые уже разработаны и все мат.модели выверены.

Ну так сразу надо было ясно вопрос задать - 
как сделать реализацию по готовой спецификации типа PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51,) ? 

И бы вам пожелал долгих лет чтобы просто прочитать эту спецификацию до конца. :bye:  

Share this post


Link to post
Share on other sites
36 минут назад, AlexandrY сказал:

И бы вам пожелал долгих лет чтобы просто прочитать эту спецификацию до конца.

Дык там все эти РФС наверно уже давно устарели и никто их не поддерживает давно, протокол-то чуть позднее интернета родился...

Share this post


Link to post
Share on other sites
20 hours ago, AlexandrY said:

И бы вам пожелал долгих лет чтобы просто прочитать эту спецификацию до конца. :bye:  

Ну я ваш стиль нагнетания ситуации и наведения ужаса уже понял, да. Спасибо )

Share this post


Link to post
Share on other sites
7 hours ago, rkit said:

Какие матмодели протоколов? Опять никакой связи с реальностью.

Можете подробнее описать вашу мысль?
Как проектируют?
Вот вы параметры CRC(не только длину, разумеется) как выбираете?
А может быть нужно не только детектировать ошибки, но и восстанавливать(избыточное кодирование).
А какие ошибки восстанавливать нужно? Сколько бит избытка будет нормально по вашему?

Ну и ещё там по мелочи что-нибудь расскажите немного об этом, если можно.
Очень интересно как оно в реальности делается....

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.