в общем дуамл, что напишу за пару часов, а почему-то угробил весь день, первый вариант готов, без потоков и со всяким мусором, но сегодня уже неохота допиливать. сначала думал допилить вчерашнюю версию, потом решил все переписать с нуля. сделал проверку контрольной суммы полученного icmp еще надо сделать проверку соответствия ip адресов и id, sequence, можно еще сделать проверку контрольной суммы полученного ip заголовка (я не знаю, как она считается, только для ip заголовка или целиком для пакета начиная от ip и до конца, если кто знает, напишите). Поток нужен, чтобы было чем убить этот поток по таймауту, если вдруг сеть не работает и recvfrom заблокировалась, если кто-то знает, как это можно реализовать без потоков, очень хотелось бы послушать. http://pastebin.com/WqPnGuzw критиковать не надо, так как это черновая версия, если конечно критика не глобалная, типа ты вообще все не так сдалал, надо совершенно иначе :)
22.11.2014 23:56, Ivan Riabtsov пишет:
Поток нужен, чтобы было чем убить этот поток по таймауту, если вдруг сеть не работает и recvfrom заблокировалась, если кто-то знает, как это можно реализовать без потоков, очень хотелось бы послушать. по поводу блокировки. Работу с сокетами можно рассматривать как как работу с обычными файловыми дескрипторами. и к ним можно применять системный вызов select() который является неблокируемым. Его, кстати часто используют в реализации серверной части на сокетах. Так обычно для получения подключения от клиентов используется вызов accept() а он блокируемый. И из-за него выход из программы возможен только после того как клиент подключиться. Что б этого не происходило используется метод select(), который выходит либо по приходу данных, либо по пришедшему сигналу (например SIG_TERM) Пример использования (первая ссылка в гугле) о том что описал выше. http://www.gnu.org/software/libc/manual/html_node/Server-Example.html http://pastebin.com/WqPnGuzw критиковать не надо, так как это черновая версия, если конечно критика не глобалная, типа ты вообще все не так сдалал, надо совершенно иначе :) Не критика, скорее рекомендации. Есть небольшое нарушение общепринятого стиля программирования "Код должен легко читаться сторонним разработчиком". Задействованы глобальные переменные, которые потом юзаются в двух функциях. Я про эти:
1. intrecv_sock,send_sock; 2. structsockaddr_in recv_sockaddr,send_sockaddr; 3. structhostent*h_ent; Мне как стороннему человеку пришлось дополнительно просматривать код, что б убедиться что отсутствует потенциальная угроза на одновременное изменение значений в этих переменных. Поэтому логичнее было бы: - эти переменные запихнуть в функцию ping() - функцию routines() дополнить необходимым параметрами и через них передать отмеченные выше переменные Возможно на это другой программист бы и не обратил внимание, но я связан с преподавательской деятельностью. И за такие недочеты снижаются оценки по разрабатываемым алгоритмам. Так что искренне надеюсь что это не воспримите близко. Тем более сами сказали, что это черновая версия ;) Код собирать пока не пробовал. так как уже чую что нужно поднимать документацию что можно было вести диалоги. Остаточных знаний по спецификации функций уже явно не хватает.
_______________________________________________ Kernel-russian mailing list Kernel-russian@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernel-russian
23.11.14, Naydin Andrey<naydinav@gmail.com> написал(а):
22.11.2014 23:56, Ivan Riabtsov пишет:
Поток нужен, чтобы было чем убить этот поток по таймауту, если вдруг сеть не работает и recvfrom заблокировалась, если кто-то знает, как это можно реализовать без потоков, очень хотелось бы послушать. по поводу блокировки. Работу с сокетами можно рассматривать как как работу с обычными файловыми дескрипторами. и к ним можно применять системный вызов select() который является неблокируемым. Его, кстати часто используют в реализации серверной части на сокетах. Так обычно для получения подключения от клиентов используется вызов accept() а он блокируемый. И из-за него выход из программы возможен только после того как клиент подключиться. Что б этого не происходило используется метод select(), который выходит либо по приходу данных, либо по пришедшему сигналу (например SIG_TERM) Пример использования (первая ссылка в гугле) о том что описал выше. http://www.gnu.org/software/libc/manual/html_node/Server-Example.html http://pastebin.com/WqPnGuzw критиковать не надо, так как это черновая версия, если конечно критика не глобалная, типа ты вообще все не так сдалал, надо совершенно иначе :) Не критика, скорее рекомендации. Есть небольшое нарушение общепринятого стиля программирования "Код должен легко читаться сторонним разработчиком". Задействованы глобальные переменные, которые потом юзаются в двух функциях. Я про эти:
1. intrecv_sock,send_sock; 2. structsockaddr_in recv_sockaddr,send_sockaddr; 3. structhostent*h_ent;
Мне как стороннему человеку пришлось дополнительно просматривать код, что б убедиться что отсутствует потенциальная угроза на одновременное изменение значений в этих переменных. Поэтому логичнее было бы: - эти переменные запихнуть в функцию ping() - функцию routines() дополнить необходимым параметрами и через них передать отмеченные выше переменные Возможно на это другой программист бы и не обратил внимание, но я связан с преподавательской деятельностью. И за такие недочеты снижаются оценки по разрабатываемым алгоритмам. Так что искренне надеюсь что это не воспримите близко. Тем более сами сказали, что это черновая версия ;)
спасибо за совет, если я правильно понимаю, то альтернативы по сути 2: 1 это как я сделал, большое количество внешних переменных 2 это локальные указатели, которые инициализируются маллоками и последующая передача указателей в функции. я так понимаю, что больше альтернатив нет? 2-й вариант боллее предпочтителен? я не имею особого опыта разработки, потому и спрашиваю :)
Код собирать пока не пробовал. так как уже чую что нужно поднимать документацию что можно было вести диалоги. Остаточных знаний по спецификации функций уже явно не хватает.
_______________________________________________ Kernel-russian mailing list Kernel-russian@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernel-russian
2014-11-22 21:56 GMT+01:00 Ivan Riabtsov <ivriabtsov@gmail.com>:
сделал проверку контрольной суммы полученного icmp
Как воспроизвести несовпадение контрольной суммы?
Првильно ли я понимаю, что проверка работает только для только что посланного запроса (на шаге n проверяется сумма пакета n-1)?
28.11.14, Alex Naumov<alexander_naumov@opensuse.org> написал(а):
2014-11-22 21:56 GMT+01:00 Ivan Riabtsov <ivriabtsov@gmail.com>:
сделал проверку контрольной суммы полученного icmp
Как воспроизвести несовпадение контрольной суммы?
Првильно ли я понимаю, что проверка работает только для только что посланного запроса (на шаге n проверяется сумма пакета n-1)?
в общем добавил в код проверку полученных icmp type и icmp code, теперь все более или менее ясно, я действительно читаю только что отправленные пакеты еще до того, как ядро успевает на них ответить, на следующей итерации читаю пакет, как раз ответ ядра но на предыдущий запрос и затем опять читаю только что отправленный пакет, интерсеная ситуация
28.11.14, Alex Naumov<alexander_naumov@opensuse.org> написал(а):
2014-11-22 21:56 GMT+01:00 Ivan Riabtsov <ivriabtsov@gmail.com>:
сделал проверку контрольной суммы полученного icmp
Как воспроизвести несовпадение контрольной суммы?
Првильно ли я понимаю, что проверка работает только для только что посланного запроса (на шаге n проверяется сумма пакета n-1)?
строки 190 - 211 если что :)
participants (3)
-
Alex Naumov -
Ivan Riabtsov -
Naydin Andrey