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

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

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

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


Сообщение отредактировал Twen - Sep 2 2011, 06:17

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

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

Сообщение отредактировал Twen - Sep 5 2011, 05:38

Не знаю даже как сформулировать вопрос. Попробу начать с предистории - есь у нас в группе программист, с опытом работы в 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 байт?