Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Сети";
Текущий архив: 2004.02.29;
Скачать: [xml.tar.bz2];

Вниз

Где присутствует параметр Gateway?   Найти похожие ветки 

 
Yaro   (2003-12-20 12:35) [0]

Предположим, что с моей машины (у которой есть статический АйПи и указанный шлюз) отправляется TCP/IP пакет. Известно, что в IP пакете присутствуют адреса отправителя и получателя, а в TCP-пакете присутствуют порты для отправителя и связующий у получателя. Причем пакет точно доходит до шлюза (вернее он его хватает) и ретранслирует, дальше - все пучком. Внимание, вопрос: Шлюз от фонаря пакеты хватает и ретранслирует или как? Если от фонаря, тогда почему, если отключить шлюз в настройках сети, то он их не хватает. Люди, подскажите откуда шлюз знает что этот пакет ему надо ретранслировать??? Хоть убей не врублюсь, хотя вру, думаю где-то это пишется, но не знаю где :)


 
Yaro   (2003-12-20 12:44) [1]

Да, и еще вот что... мне это не ради интереса, а правдо, знать надо где это пишется... и если у кого-нить есть путевая ссылка на описание структуры TCP/IP-пакетов, киньте мне, а то запарился... всю ночь сниффер писал. А вообще я NAT с ограничением по скорости писать собрался.


 
Verg   (2003-12-20 12:47) [2]

Когда нужно отправить IP пакет (а TCP пакет на данном этапе - это просто поле данных IP пакета), ядро по адресу назначения (ip_dst) получает по локальной таблице маршрутизации подходящий маршрут, т.е. интерфейс (if) через который надо отправить этот пакет и IP адрес nexthop-а (gateway). Если этот gateway == if_address (т.нз. Directly Connected Route), то пакет передается канальным уровнем этого интерфейса прямо адресату . В противном случае, пакет передается канальным уровнем этого интерфейса gateway-ю.


 
Verg   (2003-12-20 12:52) [3]

Т.е. Шлюз не "хватает" пакеты. Ip датаграммы передаются ему целенаправлено канальным уровнем.


 
Yaro   (2003-12-21 04:00) [4]

Verg, подожди, что-то я не догнал... вот структура IP-пакета:
4 бита: версия протокола IP
4 бита: количество ДВордов в заголовке IP-пакета (Size of header).
8 бит: Type of Service - назначение сего мне не совсем понятно.
16 бит: общая длинна пакета (насколько я знаю - в байтах).
16 бит: идентификация, пакеты, которые являются частью одного ПАКЕТА имеют одинаковый идентификатор (есть некоторые вопросы).
3 бита: флаги фрагментации (только два - один для обозначения фрагментированного пакета, другой - для обозначения последнего пакета, третий зарезервирован).
13 бит: смещение фрагмента (есть вопросы).
8 бит: TTL, вроде все понятно, но есть вопросы.
8 бит: Протокол верхнего уровня.
16 бит: Контрольная сумма (сумма чего? едениц в заголовке пакета или как? Если так, то входит ли сюда значения самого этого поля?).
32 бита: Ип отправителя.
32 бита: Ип получателя (конечного).
(n mod 32)=0: Опции и заполнение (вот, это-то меня и интересует больше всего!).
TotalLen-4*HeadLen: Data (правильно?)
-----
И где тут указание шлюза? Может это указано в поле Опции? или как? Если можешь - разъясни некоторые моменты по IP-пакету: моменты связаны с фрагментацией. Насколько я понял - данные могут быть раздроблены на пакеты равной длинны (кроме последнего или нет?) и параметр смещение фрагмента определяет какой кусок надо ложить первым (0), какой вторым (1), а какой третим (1). Тоесть пакеты могут передаваться через разные маршруты одному пункту назначения, тем самым обеспечивая "больше скорость", и пакеты могут приходить не только последовательно, но и вразнобой, так или нет?

И еще, функция recv возвращает колическтов принятых байт, причем один прием - один IP-пакет (фрагмент еще не готового БОЛЬШОГО пакета или он сначала компонуется полностью, а потом передается в recv?), я прав?

Да и еще, если я на сервере буду задерживать принимаемые пакеты, и тем самым добьюсь ограничения по скорости, нужно ли мне изменять поле TTL на н-секунд, а если я не буду задерживать, то мне изменять поле TTL на одну секунду в меньшую сторону или нет?

Пожалуйста, просвятите неграмоного, буду очень благодарен.
Заранее спасибо!


 
panov   (2003-12-21 14:13) [5]

Причем здесь пакет?

Тебе же ясно написали, что этим занимается ядро системы.


 
Yaro   (2003-12-22 00:48) [6]

panov:
Какой, блин, еще системы? Здесь есть только кабель, хабы и пакеты? Или это на уровне МАС организовывается, если так, то объясните каким образом...


 
panov   (2003-12-22 12:00) [7]

Какой, блин, еще системы? Здесь есть только кабель, хабы и пакеты? Или это на уровне МАС организовывается, если так, то объясните каким образом...

А пакет-то где изначально формируется?
Ведь не на хабе и ни сам по себе появляется.

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


 
panov   (2003-12-22 12:01) [8]

И вообще понятие Gateway(маршрутизатор) присутствует в списках маршрутизации хоста, но никак не в пакетах.


 
Multiplayer   (2003-12-22 18:59) [9]

Yaro, я тебе щас скину на мыло статейку, OK?


 
Yaro   (2003-12-23 02:20) [10]

panov ->
Другими словами, можно смело на сервере ловить все пакеты, которые предназначемы всем адресам кроме (192.168.x.x и тому подобных), корректировать и передавать их по и-нетовскому соединению? и наоборот... короче свитчи сами разберутся куда пакет шуровать, я правильно понял?
Multiplayer ->
Я не против, даже за, только где статейка-то?


 
Verg   (2003-12-23 11:12) [11]


> Yaro © (23.12.03 02:20) [10]
> panov ->
> Другими словами, можно смело на сервере ловить все пакеты,
> которые предназначемы всем адресам кроме (192.168.x.x и
> тому подобных), корректировать и передавать их по и-нетовскому
> соединению? и наоборот... короче свитчи сами разберутся
> куда пакет шуровать, я правильно понял?


Ты вообще представляешь как происходит передача датаграм в сети, допустим, ethernet?

Про передачу пакетов TCP/IP по ethernet"у рассказывается в RFC894

Ethernet"овское железо обеспечивает сырую передачу пакетов.
Контроллер сам считает и проверяет контрольную сумму, умеет из
приходящего потока отсеивать только пакеты, предназначенные ему или
broadcast"ы, борется с коллизиями на сети. Прежде, чем отдать
пакет контроллеру, следует заполнить поля в заголовке. При приеме
контроллер сам анализирует поле адреса получателя и отбрасывает
пакеты, не имеющие к нам отношения. Обработка контрольной суммы
и коллизий пользователю не видна.

Пакет состоит из ethernet-овского заголовков, прямо за которым следуют
данные. Формат заголовка следующий:

typedef struct
{
uchar dest[6];
uchar source[6];
ushort type;
}
eth_header;

dest и source - адреса отправителя и получателя пакета, соответственно.
type - тип пакета. Нас интересует только два типа:

#define ETHER_TYPE_IP 0x800 // Пакеты IP
#define ETHER_TYPE_ARP 0x806 // Пакеты ARP

type передается, естественно, в сетевом порядке байт.

Сразу за заголовком идет блок данных - IP или ARP пакет.

Ethernet-адреса (MAC - адреса) - это некоторые 6-байтовые числа, от которых требуется уникальность. Уникальность обеспечивается производителями контроллеров.
Адрес, состоящий из одний единиц (ff:ff:ff:ff:ff:ff) - это бродкаст.
Бывают еще мультикасты, пакеты, предназначенные группе машин на сети. Для этого конктроллеру можно скормить сполдюжины адресов, на которые он будет откликаться дополнительно к его собственному адресу и бродкасту.


 
Verg   (2003-12-23 11:41) [12]

И еще. Читай про модель OSI.



Страницы: 1 вся ветка

Форум: "Сети";
Текущий архив: 2004.02.29;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.48 MB
Время: 0.01 c
6-94077
Gefest
2003-12-22 20:35
2004.02.29
Массив по сети


3-93797
Victor!
2004-01-31 15:12
2004.02.29
Вопрос по Microsoft Jet


3-93770
Шоломицкий
2004-02-04 11:41
2004.02.29
Как связать ADOConnection


14-94148
Knight
2004-02-04 23:41
2004.02.29
Есть ли место 486-му в современной локалке?


14-94143
heady
2004-02-02 20:40
2004.02.29
Delphi 7 Help





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский