Добрый вечер.
Решил заняться освоением tcp/ip протокола. Все книги, которые я встречал по tcp/ip протоколу не совсем для начинающих, как мне кажется...я работаю с железом уже пару лет, но с сетью никогда не работал, решил разобраться.
Может вы знаете какие-то легко читаемые книги по tcp/ip ? Искал книгу tcp/ip для чайников, но не нашел где можно ее скачать, уже готов даже купить, но в интернет магазиназ тоже нету...
Я использую для обучения отладочную плату на stm32f107 и разбираюсь с примером, который построен на uip 1.0.
Как вы считаете для того, чтобы разобраться с uip стеком сколько времени нужно в среднем ?

тут неплохо описано: http://ipm.kstu.ru/internet/lec/1.php

Спасибо, да действительно не плохо написано, вот здесь так себе...



Хотел, также, спросить по поводу стека tcp/ip. Для использования tcp/ip какие варианты реализации стеков есть. Я знаю есть Light tcp/ip, uIP есть еще что-нибудь, включая платные? Хочу использовать стек на МК 32-ух разрядном. И какой лучшее посоветуете...нужно не сильно тяжелый и гибкий.

Немного почитав, был реализован веб-сервер на микроконтроллере, но для входа на сайт я использую его ip адрес...я читал, что есть DNS сервер, который преобразует доменное имя в ip адрес девайса.
Каким образом мне можно было создать свое доменное имя? Это нужно чтобы прибор поддерживал DNS протокол и при запросе по доменному имени отправлял ip адрес?

Купить домен под прибор
Вам придется реализовать DNS сервер в приборе, а затем его IP прописать в сетевых настройках компьютера, откуда вы собираетесь обращаться к прибору.
Мне кажется, что это проблемы не решит
Пропишите имя вашего прибора и IP в hosts на компьютере (<WINDOWS DIR>\system32\drivers\etc\hosts)

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

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

Мой компьютер подключен к беспроводному модему, через который я получаю выход в интернет. Я в сетях особо не сильно пока что разбираюсь...Так вот , у меня есть мой компьютер и прибор - веб-сервер, я их хочу подключить к свичу ,а свитч потом подключить к беспроводному USB модему, чтобы 2 прибора имели независимый выход в интернет, правильно?

Нет. Вам нужен статический IP с внешним именем. Поинтересуйтесь у своего Интернет провайдера
Нет
Если вы хотите уникальное доменное имя, то да.

Даже по IP может не загрузится. IP должен быть статический и внешний. Обычно такие дают за деньги и по явному требованию.
При таком включении ваш прибор сможет сам ходить в интернет, а вот что бы интернет ходил к нему - тут уже нужно немного больше (см. выше)

Необязательно. Есть DynDNS, No-Ip.com и другие подобные сервисы.


Для начала - надо проверить не поддерживается какой-нибудь из них прямо в модеме (раутере). Если нет - тогда придется на комп небольшую программку ставить.
Сам девайс будет с внутренним IP, а в роутере надо сделать на него проброс (виртуальным сервером и и.п.).

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

Тогда "ой"!
Просто у нас такого не бывает - нет "домОвых интернетов".

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

Где находится 'удаленный веб сервер'? Если у друга (на хостинге), то вы не сможете с него добраться до вашего прибора, если локально у вас (около прибора), то с сайта вашего друга нельзя будет добраться до вашего 'удаленного сервера'.
Проблема как видим осталась

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

Друг заказал сайт, ему сделали...он представитель одного предприятия, по его просьбам сайт регулярно обновляется. Так вот если на его сайте реализуют прокси сервер, то этот прокси сервер будет делать запрос моему веб серверу, для запроса нужен статический ip адрес, как быть с ним, обязательно нужно покупать? Или можно как-то сделать и через динамический? И на веб сервере нужно будет реализовывать какой-то протокол верхнего уровня для обслуживания запросов прокси сервера ?
Спасибо.

Обновлять сайт и хостить на нем самопальные серверы - это как говорится 2 большие разницы

Не так. Прокси сервер должен предоставлять входящее соединение для вашей железки. Т.е. железка должна стартовать и сама подсоединяться к специальному порту на прокси сервере.

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

Если ваше уст-во будет постоянно (примерно раз в 30-60 сек)напоминать серверу вашего приятеля , свой IP и порт, то возможно до него можно будет достучаться. Что-то подобное делаю Скайп и тп.
Можно еще почитать про STUN(Session Traversal Utilities for NAT), не разбирался с этим, но он , помоему, тоже для этого.

Тут очень много особенностей, в том числе зависящих от провайдера. Стрим, к примеру, фильтрует по входящим запросам уйму портов, в том числе и 80 - порт HTTP. Поэтому я бы Вам посоветовал прежде, чем что-то покупать проконсультироваться на месте с человеком, знакомым с TCP/IP, NAT, пробросами портов, DNS и пр. Иначе можно сильно наступить на грабли.

Ясно, не все так просто...проще было просто купить отдельное доменное имя и статический ip.

Хотел вернуться к вопросу по литературе, как по мне то довольно неплохая книга доктора Дугласа Э.Камера, признаного в мире специалиста по протоколу tcp/ip. Она переведена на русский. В ней есть описание основных протоколов tcp/ip, а также описание интерфейса прикладных программ API.

Также, хотел спросить, какую программу (снифер) вы посоветуете для отладки какого-либо приложения прикладной программы для начинающего (желательно чтобы можно было посмотреть весь ethernet frame, который будет состоять из пакета ip, tcp...) ? Я пользовался tcpdump, но мне как-то не понравилось или может не полностью разобрался с возможностями, есть ли что-либо другое, удобное для отладки?

wireshark
Несмотря на монстроидальность.

Мне понравилась, спасибо!
И вот неплохая статья, в которой можно посмотреть ее использование.

Не знаю даже как сформулировать вопрос. Попробу начать с предистории - есь у нас в группе программист, с опытом работы в tcp/ip, сам я в этом разбираюсь на уровне "знаю что оно есть, и примерно что собой представлет", не более того. Нужно ему поставиь задачу. а заодно и лдля себя кое-что уяснить.
Проблема заключается в том, что этот программист довольно нужный товаришь возраста за 50, совершено лишенный всякой фантазии и инициативы - от него может и избавились бы давно, но он во первых какой-то альний родственник босса, в по вторых - нельзя не сказать что ео программы )или куски программ) всегда отлично оформлены, отлажены и хорого работают. Но(!) - ему надо все разжевать и в рот положить, сам напрягатсья не будет.
Теперь сама задача - есть АРМ (пока Кортекс М3, но если припрет - перейдем на что-то другое), включенный эзернетом в локальную сеть.
С одного из компов этой сети, он должен брать файл (имя известно заранее, размер файла может быть большой) и выдаь его в ЦАП процессора.
В другом режиме - наоборот (т.е. с АЦП в файл). Естественно все в реалтайме, поток данных - примерно 1-1.5 мбайта.сек.

Как вариант, думаем поставить на комп FTP-сервер, а на МК - FTP-клиент. Все IP - фиксированные. Вот дальше, темный лес - правильный ли выбор ftp ? По tcp или udp ?

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

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

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

FTP вам не подойдет - он с реалтаймовостью не дружит Делайте на обычных сокетах - на компе сервер, слушающий сокет, на МК клиент, подсоединяющийся к серверу и заливающий данные. Протокол лучше брать TCP

А HTTP дружит с реалтаймовостью? Хотелось бы, по возможности, обойтись без написания программм под РС а использовать имеющиеся, потому и FTP/HTTP.

Без написания программ под РС передачу больших файлов через HTTP Вы все равно не решите. На сокетах будет куда проще.

Нет
Для этого ваши 'имеющиеся' должны быть real-time. Никакие обычные WEB сервисы не являются таковыми (кроме всякой multimedia streaming )

Так может им и воспользоваться? DLNA какое-нибудь?
Только всеже никто не ответил именно на те вопросы что я задавал =- сколко минимум буфера в МК надо, и как все это обьяснить тому программеру ?



А можно чуть поподробнее? Или где об этом почитать ?

Изготовление Media Streaming сервера в МК задача на много порядков более сложная, чем написание необходимой программы для РС. Да и Cortex M3 не потянет
Это зависит от задачи. Буфер нужен для буферизации передаваемых данных и для работы самого стека TCP/IP. Последнее зависит от стека, который вы будете применять. Их много разных есть

Куда же подробнее. Самый примитивный TCP сервер. Открыл сокет (socket), дал ему адрес (bind), сказал, что это будет сервер (listen) и ждешь входящего соединения (accept). Далее читаешь/пишешь из него (read/write)

Ну так нам не кино в FullHD передавать В МК и обработки в этом режиме никакой - принять с сервера и выплюнуть в SPI, в одном случае, и считать с SPI и передать на сервер в другом.



Насколько я знаю, сейчас программист использует RTL Кейла, с вопрос про буфер - хватит ли внутренней памяти LPC1769 или надо внешнюю?
И если надо - то сколько? Если это несколько десятков килобайт, то я поставлю на другой SPI одну-две 23K256, а если сотни - то придется на другой проц переходить, с внешней шиной, чобы параллельной ОЗУ прицепить.
(попутно вопрос - не знат ли кто ОЗУ с SPI, большего размер ачем 256кбит? Все что я находил - это совмещенные RAM-EEPROM-RTC, которые подойтут, но они мягко говоря не очень дешевые.)



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

А это не важно, что передавать. Протокол стримера все равно придется реализовывать. А это явно перебор
Определитесь сначала с протоколом передачи данных. Хотя бы на уровне TCP vs UDP
TCP гарантирует доставку данных, но не гарантирует задержку. UDP не гарантирует доставку, но (с некоторыми ограничениями в использовании) можно оценить время доставки (нижний и верхний порог). Так что вокруг UDP придется сделать еще какой то протокол (например ввести избыточность в виде 1 лишнего пакета на N пакетов данных). Вот этот протокол может потребовать памяти для работы (N+2 буферов для данных)

Это позволит исправить ошибку (недошедший пакет) или только диагностировать?
"Пакет" - это 512 байт?

Исправить
Пакет - это одна UDP datagram'а, желательно размером не больше Ethernet фрейма (за вычетом заголовков Ethernet/IP/UDP). Т.е. около 1-1.5К (Можно меньше)

Если N=4, этого будет достаточно как Вы думаете ?
5 буферов по 1-1.5к найдутся во внутренней памяти.

А это зависит от параметров вашей сети и требований на задержки при передаче данных.

Возможно их понадобится раза в 2 больше Или придется делать весьма нетривиальные алгоритмы по перераспределению буферов в процессе приема/выдачи на ЦАП.
Кроме того, надо предусмотреть управление скоростью потока передаваемых данных - она должна строго совпадать с скоростью выдачи данных на ЦАП.

В общем задача не простая

Немного расширили мою тему)...
Товарищи, я ищу для микроконтроллера серии stm32F подходящий стек TCP/IP, погуглив налел неплохую статью по поводу стеков для этих микроконтроллеров.

Имеются стеки :

Производитель - Стек

1) CMX Systems - CMX-TCP/IP
2) Express Logic - NetX
3) IAR - PowerPac TCP/IP
4) InterNiche - NicheLite
5) Keil - RL-TCPnet
6) Micrium - uC/TCP-IP
7) Micro Digital - smxNS
8) RTXC-Quadros - RTXC
9) Segger - embos/IP

В большинстве случаев стеки могут идти отдельно от ОС...
Дело в том, что стек нежен на ОС, использоваться будет возможно в коммерческих целях. Выходит плясать у выборе стека нужно исходя из операционной системы, которая будет использоваться. Если кто-то может, что-то посоветовать пишите. Так как для проекта будет использоваться ОС, то разумеется он будет не простым, планируется реализация http и lftp. Хотелось бы реализовать проект на условно-бесплатной ОС , а стек докупить...но на сколько я понял все высшее перечисленные ОС есть платными...

Ну я предполагал два буфера - в один идет прием, с другого выдача в ЦАП.




Тут не очень понятно. Я предполагал так:
- скорость приема больше скорости выдачи в ЦАП
- принимаем с LAN в один буфер, и останавливаемся по его заполнению.
- со второго буфера выдаем в ЦАП.
- когда все выдали, переключаемся на выдачу с первого буфера
- прием с LAN преключаем на второй буфер и начинем прием до его заполнения.
- и так по кругу.

Если требуется какая-то обработка, то понадобится 3 буфера: в первый принимаем, по заполнению переписываем с обработкой во второй, из третьего выдаем в ЦАП. Потом 2-й и 3-й меняются местами.
Т.е. 1-й буфер понадобится размером с "сырые данные" (до исправления), 2-й и 3-й - размером с "чистые данные".
Гнать в ЦАП можно без участия CPU - по DMA, с автосменой буферов (LLI) и прерыванием по их смене.

Или сервер будет тупо передавать пакеты, невзирая на клиента, и его не "поставить на паузу" ?
Я как уже говорил, мало понимаю в TCP/IP, но мне казалось там есть какое-то подобия квитирования.

Именно.
В TCP есть, в UDP нет.

Значит, UDP не годится.
Но как-же тогда работают вообще протоколы пеердачи на основе UDP? Они предполагают, что приемник "всегда готов" Т.е. что он заведомо быстрее передатчика ?

Они ничего не предполагают
Да

Не совсем. Либо скорость потока данных определяется именно передатчиком (как во всяких multimedia стримерах), либо вводят синхронизацию скорости в протокол

Значит отнозначно TCP - в этом проекте квитированием и скоростью (которая может быть и раной) должен рулить МК.

На что основное стоит полагаться при выборе API для LwIP. Реализация примеров приложений верхних уровней с использованием LwIP под stm32f207 на FreeRTOS сделана на 2 разных API:

- Netconn API is a high-level sequential API that requires the services of a real-time
operating system (RTOS). The Netconn API enables multi-threaded operations.
- BSD Socket API: Berkeley-like Socket API (developed on top of the Netconn API)

Какие можно выделить преимуществе одной по отношению к другой?

Netconn API - это родное API в LwIP
BSD Socket API построено поверх Netconn API

Если у вас уже есть программа на сокетах (это и есть BSD Socket API), или вы их когда либо применяли - используйте BSD Socket API. Если нет, то берите родное Netconn API, зачем вам лишние уровни софтового стека?

Спасибо за внятное разъяснение. На сколько я знаю BSD soket используются в ОС Unix и как бы для большей унификации иногда поверх определенного иного api(в нашем случае Netconn API) пишут еще один уровень API, к которому будут привязываться (в нашем случае BSD Socket API).
Теперь стало понятно зачем в демке есть два примера под разные API.
Я не работал и не привязываюсь к каким-то модулям программы, в которых используются BSD socket. По этому с целью экономии ресурсов(памяти) действительно лучшее выбрать Netconn API.