|
|
  |
Старт с tcp/ip, Советы по литературе |
|
|
|
Aug 30 2011, 21:27
|
Профессионал
    
Группа: Свой
Сообщений: 1 526
Регистрация: 8-04-05
Пользователь №: 3 960

|
Цитата(Twen @ Aug 29 2011, 15:57)  Или можно как-то сделать и через динамический? И на веб сервере нужно будет реализовывать какой-то протокол верхнего уровня для обслуживания запросов прокси сервера ? Тут очень много особенностей, в том числе зависящих от провайдера. Стрим, к примеру, фильтрует по входящим запросам уйму портов, в том числе и 80 - порт HTTP. Поэтому я бы Вам посоветовал прежде, чем что-то покупать проконсультироваться на месте с человеком, знакомым с TCP/IP, NAT, пробросами портов, DNS и пр. Иначе можно сильно наступить на грабли.
|
|
|
|
|
Sep 2 2011, 05:24
|
Частый гость
 
Группа: Участник
Сообщений: 163
Регистрация: 7-02-09
Пользователь №: 44 543

|
Хотел вернуться к вопросу по литературе, как по мне то довольно неплохая книга доктора Дугласа Э.Камера, признаного в мире специалиста по протоколу tcp/ip. Она переведена на русский. В ней есть описание основных протоколов tcp/ip, а также описание интерфейса прикладных программ API.
Также, хотел спросить, какую программу (снифер) вы посоветуете для отладки какого-либо приложения прикладной программы для начинающего (желательно чтобы можно было посмотреть весь ethernet frame, который будет состоять из пакета ip, tcp...) ? Я пользовался tcpdump, но мне как-то не понравилось или может не полностью разобрался с возможностями, есть ли что-либо другое, удобное для отладки?
Сообщение отредактировал Twen - Sep 2 2011, 06:17
|
|
|
|
|
Sep 5 2011, 05:36
|
Частый гость
 
Группа: Участник
Сообщений: 163
Регистрация: 7-02-09
Пользователь №: 44 543

|
Цитата wireshark Несмотря на монстроидальность. Мне понравилась, спасибо! И вот неплохая статья, в которой можно посмотреть ее использование.
Сообщение отредактировал Twen - Sep 5 2011, 05:38
|
|
|
|
|
Sep 6 2011, 15:18
|
Профессионал
    
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763

|
Не знаю даже как сформулировать вопрос. Попробу начать с предистории - есь у нас в группе программист, с опытом работы в tcp/ip, сам я в этом разбираюсь на уровне "знаю что оно есть, и примерно что собой представлет", не более того. Нужно ему поставиь задачу. а заодно и лдля себя кое-что уяснить. Проблема заключается в том, что этот программист довольно нужный товаришь возраста за 50, совершено лишенный всякой фантазии и инициативы - от него может и избавились бы давно, но он во первых какой-то альний родственник босса, в по вторых - нельзя не сказать что ео программы )или куски программ) всегда отлично оформлены, отлажены и хорого работают. Но(!) - ему надо все разжевать и в рот положить, сам напрягатсья не будет. Теперь сама задача - есть АРМ (пока Кортекс М3, но если припрет - перейдем на что-то другое), включенный эзернетом в локальную сеть. С одного из компов этой сети, он должен брать файл (имя известно заранее, размер файла может быть большой) и выдаь его в ЦАП процессора. В другом режиме - наоборот (т.е. с АЦП в файл). Естественно все в реалтайме, поток данных - примерно 1-1.5 мбайта.сек.
Как вариант, думаем поставить на комп FTP-сервер, а на МК - FTP-клиент. Все IP - фиксированные. Вот дальше, темный лес - правильный ли выбор ftp ? По tcp или udp ?
Меня, как больше занимающегося железом чем софтом, интересует какие могут быть задержки с приемом пакетов в тиакой конструкции? Как я уже сказал - работа реалтаймовая, перебои в потоке данных не катастрофичны (т.е. нико не умрет и ничгео не сломается), но эксперимент прижется начинать заново. Т.е. форулируя вопрос по этому пункту более окнкретно - какой минимально необходимый буфер (FIFO) надо предусмотреть в МК (от этого будет зависеть и окончателный выбор самого МК).
Еще задумка на будующее - на этот-же МК поставить и веб-сервер, самый простой, чтобы через него рулить параметрами и режимами. Тут скорости не надо, больших обьемов пересылаемых данных тоже, хотя если бы через него и апгрейд фирмваре сделать, было бы просто идеально - тут бы тоже буфер не помешал.
Может несколько сумбурно написал, но надеюсь на полезные советы.
|
|
|
|
|
Sep 7 2011, 10:48
|
Гуру
     
Группа: Свой
Сообщений: 3 123
Регистрация: 7-04-07
Из: Химки
Пользователь №: 26 847

|
Цитата А HTTP дружит с реалтаймовостью? Нет Цитата Хотелось бы, по возможности, обойтись без написания программм под РС а использовать имеющиеся, Для этого ваши 'имеющиеся' должны быть real-time. Никакие обычные WEB сервисы не являются таковыми (кроме всякой multimedia streaming  )
|
|
|
|
|
Sep 7 2011, 13:49
|
Профессионал
    
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763

|
Цитата(XVR @ Sep 7 2011, 12:48)  Нет Для этого ваши 'имеющиеся' должны быть real-time. Никакие обычные WEB сервисы не являются таковыми (кроме всякой multimedia streaming  ) Так может им и воспользоваться? DLNA какое-нибудь? Только всеже никто не ответил именно на те вопросы что я задавал =- сколко минимум буфера в МК надо, и как все это обьяснить тому программеру ? Цитата На сокетах будет куда проще. А можно чуть поподробнее? Или где об этом почитать ?
|
|
|
|
|
Sep 7 2011, 17:28
|
Гуру
     
Группа: Свой
Сообщений: 3 123
Регистрация: 7-04-07
Из: Химки
Пользователь №: 26 847

|
Цитата(Allregia @ Sep 7 2011, 17:49)  Так может им и воспользоваться? DLNA какое-нибудь? Изготовление Media Streaming сервера в МК задача на много порядков более сложная, чем написание необходимой программы для РС. Да и Cortex M3 не потянет Цитата Только всеже никто не ответил именно на те вопросы что я задавал =- сколко минимум буфера в МК надо, Это зависит от задачи. Буфер нужен для буферизации передаваемых данных и для работы самого стека TCP/IP. Последнее зависит от стека, который вы будете применять. Их много разных есть Цитата А можно чуть поподробнее? Или где об этом почитать ? Куда же подробнее. Самый примитивный TCP сервер. Открыл сокет (socket), дал ему адрес (bind), сказал, что это будет сервер (listen) и ждешь входящего соединения (accept). Далее читаешь/пишешь из него (read/write)
|
|
|
|
|
Sep 8 2011, 08:38
|
Профессионал
    
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763

|
Цитата Изготовление Media Streaming сервера в МК задача на много порядков более сложная, чем написание необходимой программы для РС. Да и Cortex M3 не потянет Ну так нам не кино в FullHD передавать  В МК и обработки в этом режиме никакой - принять с сервера и выплюнуть в SPI, в одном случае, и считать с SPI и передать на сервер в другом. Цитата Это зависит от задачи. Буфер нужен для буферизации передаваемых данных и для работы самого стека TCP/IP. Последнее зависит от стека, который вы будете применять. Их много разных есть Насколько я знаю, сейчас программист использует RTL Кейла, с вопрос про буфер - хватит ли внутренней памяти LPC1769 или надо внешнюю? И если надо - то сколько? Если это несколько десятков килобайт, то я поставлю на другой SPI одну-две 23K256, а если сотни - то придется на другой проц переходить, с внешней шиной, чобы параллельной ОЗУ прицепить. (попутно вопрос - не знат ли кто ОЗУ с SPI, большего размер ачем 256кбит? Все что я находил - это совмещенные RAM-EEPROM-RTC, которые подойтут, но они мягко говоря не очень дешевые.) Цитата Куда же подробнее. Самый примитивный TCP сервер. Открыл сокет (socket), дал ему адрес (bind), сказал, что это будет сервер (listen) и ждешь входящего соединения (accept). Далее читаешь/пишешь из него (read/write) Ну, для меня не очень понятно, лучше бы пример какой посмотреть, но программисту попробую передеть, может ему будет понятно. В любом случае, спасибо за советы.
|
|
|
|
|
Sep 8 2011, 08:47
|
Гуру
     
Группа: Свой
Сообщений: 3 123
Регистрация: 7-04-07
Из: Химки
Пользователь №: 26 847

|
Цитата Ну так нам не кино в FullHD передавать А это не важно, что передавать. Протокол стримера все равно придется реализовывать. А это явно перебор Цитата Насколько я знаю, сейчас программист использует RTL Кейла, с вопрос про буфер - хватит ли внутренней памяти LPC1769 или надо внешнюю? Определитесь сначала с протоколом передачи данных. Хотя бы на уровне TCP vs UDP  TCP гарантирует доставку данных, но не гарантирует задержку. UDP не гарантирует доставку, но (с некоторыми ограничениями в использовании) можно оценить время доставки (нижний и верхний порог). Так что вокруг UDP придется сделать еще какой то протокол (например ввести избыточность в виде 1 лишнего пакета на N пакетов данных). Вот этот протокол может потребовать памяти для работы (N+2 буферов для данных)
|
|
|
|
|
Sep 9 2011, 07:53
|
Профессионал
    
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763

|
Цитата например ввести избыточность в виде 1 лишнего пакета на N пакетов данных Это позволит исправить ошибку (недошедший пакет) или только диагностировать? "Пакет" - это 512 байт?
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|