Изменить UDP-заголовок руками в сокете?

[Артем]

 Добрый день/вечер.

 Прога посылает UDP-пакеты. Раньше они формировались "руками" (без использования ВинСокет), и, исторически так сложилось, что в поле  "Порт источника" UDP-заголовка заноситься совсем другая инфа (а вовсе не порт источника ).
 Теперь мне этот же пакет надо сформировать сокетом (WSASocket, bind  и все такое ). Но вот, что то я никак не найду как записать нужное мне значение в в поле  "Порт источника" UDP-заголовка и можно ли до этого поля "достучаться" в сокетах?
 

[RXL]

struct sockaddr_in sa;
sa.sin_family=AF_INET;
sa.in_addr.sin_addr=htonl(0x00000000); // любой локальный ip
sa.sin_port=htons(1234); // номер порта
bind(sock,(struct sockaddr*)&sa,sizeof(sa));

Если порт не занят другим приложением, то должно работать.

[Артем]

sa.sin_port=htons(1234); // номер порта

 это, по-моему,  порт "куда шлем", т.е. поле "Порт назначения" (поправьте, если не прав), а я имею ввиду поле "Порт источника", т.е. "откуда шлем" ....
 
 

[RXL]

Нет. вind() назначает локальный порт. Порт назначения можно установить через sendto() или connect() (возможно что второй вариант в винде не сработает).

[Артем]

 Спасибо,  RXL!
 
 все правильно, вind() действительно назначает локальный порт, проверил и даже работает!

а я сегодня болею, торможу и все такое...
пора домой ...

[npak]

Для меня новость, что bind позволил привязать адрес, которого нет на узле. Надо будет проверить на других осях, не Windows.

[RXL]

npak, ты надеюсь не о 0.0.0.0?

[Артем]

у меня не получилось

привязать адрес, которого нет на узле.

(правда я пытался привязать толко 255.255.255.255 )
 
 IP-пришлось писать свой, но мне другой и не надо было .

Мне нужно было "привязать"  порт источника, что успешно и удалось сделать!!!

[npak]

Пардон, торможу.

Да, для установки поля "Порт источника" действительно надо привязать сокет к любому из локальных адресов, а ещё лучше к 0.0.0.0 что бы не возиться с выбором подходящего адреса.

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

[Артем]

Может немного странный вопрос, но все же:

 Как гарантировать что я данный порт ВСЕГДА будет свободным для того чтобы назначить его как "порт источника"?

Немного поясню вопрос.
 1. Это надо гарантировать на данном конкретном компьютере (под Win2000), сейчас у меня полный доступ к нему, но через пару месяцев он уйдет, и мне будет до него не добраться...
 2. номера портов: 1,2,3 и 4. Вот что я про них нашел:
            1=TCP-MUX - TCP Port Service Multiplexer
            2=COMPRESSNET - Management Utility
            3=COMPRESSNET - Compression Process
            4=про него ничего не нашел

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

[RXL]

npak, кстати в Linux-е можно сделать bind() к чужому адресу, если поставить галочку в /proc. Я, правда, до исследования этого вопроса не добрался. Если будешь проверять - скажи результат.

[npak]

Артём,
НИКАК

Но с высокой вероятностью порты с номерами больше 10 000 будут свободны.

Я обычно для экспериментов выбираю порты от 20000 и ещё ни разу не сталкивался с проблемами.

RXL, у меня сейчас нет Linux, поэтому проверить найденную тобой фичу я не могу.

[Артем]

npak, почему "НИКАК"?
а если "снести" с компа (и запретить в дальнейшем устанавливать) всё что может занять данные порты? Или, как вариант, оставить на компе только те приложения, которые гарантировано не займут эти порты.


Спрошу иначе:
 
  Что мне снести из системы (Win2000),  и что мне запретить пользователю устанавливать на данный комп, что бы порты с 1 по 8, были свободны (причем свободны как "порт источника")?

[npak]

посмотри c:/WINDOWS/system32/drivers/etc/servics
В этом файле указаны стандартные сетевые сервисы и их привязки к портам.  На моей машине в указанном тобой диапазоне есть только сервис echo (udp echo server)
Я провёл небольшой эксперимент по проверке доступности портов.  На моей Windows XP все порты с 1 до 8 свободны.

[RXL]

npak, конечно - это ж все unix-сервисы тестового назначения. Использование их на windows-машине весьма сомнительно.

[npak]

RXL,

это стандартные привязки сетевых сервисов к портам и не зависят от операционной системы.
Другое дело, что реализации этих сервисов присутствуют, как правило, только на юниксах,и , следовательно, на windows эти порты свободны.

[Артем]

  Спасибо, за ответы
У меня эти порты тоже свободны и вроде все работает

Единственное, на всякий случай, когда комп отдавать буду скажу, чтоб не ставили приложения которые занимают порты с 1 по 8

[maa]

Если нужный тебе порт занят, его всё же можно использовать, если установить опцию SO_REUSEADDR с помощью setsockopt().