Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Еще одна фигня с send 04.06.03 18:29
Автор: PS <PS> Статус: Elderman Отредактировано 04.06.03 18:33 Количество правок: 1
|
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 xxxx.4001 yyyy.1225 ESTABLISHED
tcp4 0 1220 xxxx.4000 yyyy1224 ESTABLISHED
В сокете на отправку лежат 1220 байт, и не уходят !
#define SOCKET_ERROR -1
...
int flag;
flag = 0;
int res = send( m_sock_writer, buffer, packetSize + sizeof(long), flag );
if( res == SOCKET_ERROR )
{
m_log->Msg( 1, "WARNING ! Send socket was closed ! Restart your client !\n" );
// We will restart writer socket in READ function !
// READ function always catch error in connection, becouse stay on recv()
delete[] buffer;
return;
}
m_log->Msg( 0, "WRITER: OK.\n" );
---
Вот так, send() мне не возвращает -1. Типа все отправил, все ок. А на самом деле данные лежат в очереди, и их не могут получить.
Кто с такой фигней встречался ? Из-за чего может быть ?
P.S. OS: FreeBSD
P.P.S: блин, ну почему в виндах ни разу такой фигни не возникало !
|
 |
Требуется помощь... 06.06.03 14:17
Автор: PS <PS> Статус: Elderman
|
В продолжение топика.
Ситуация сложиласть следующим образом:
Есть некий хост CCC, за ним сидят две машины AAA и BBB.
Если мы запустим клиент с машины AAA, то описанной в топике проблеммы не будет. Если запусим с BBB то проблемма возникает стабильно.
Коннект клиентов идет к некому хосту DDD.
Было произведенно сравнение параметров ядра машин AAA и BBB.
В листиге: AAA это <
BBB это >
И так < - работает нормально
> - теряет соединение после таймаута.
Кто знает за что отвечают нижеприведенные настройки, будте добры написать. И какая из настроек может вызывать проблемму.
< net.inet.ip.forwarding: 1
---
> net.inet.ip.forwarding: 0 24a25,35
> net.inet.ip.dummynet.hash_size: 64 > net.inet.ip.dummynet.curr_time: 1105839154 > net.inet.ip.dummynet.ready_heap: 0 > net.inet.ip.dummynet.extract_heap: 0 > net.inet.ip.dummynet.searches: 0 > net.inet.ip.dummynet.search_steps: 0 > net.inet.ip.dummynet.expire: 1 > net.inet.ip.dummynet.max_chain_len: 16 > net.inet.ip.dummynet.red_lookup_depth: 256 > net.inet.ip.dummynet.red_avg_pkt_size: 512 > net.inet.ip.dummynet.red_max_pkt_size: 1500 29c40
< net.inet.ip.fw.verbose_limit: 0
---
> net.inet.ip.fw.verbose_limit: 100 32c43
< net.inet.ip.fw.dyn_count: 107
---
> net.inet.ip.fw.dyn_count: 0 34c45
< net.inet.ip.fw.static_count: 34
---
> net.inet.ip.fw.static_count: 1 42,44c53
< net.inet.ip.maxfragpackets: 79
< net.inet.ip.maxfragsperpacket: 16
< net.inet.ip.sendsourcequench: 0
---
> net.inet.ip.maxfragpackets: 632 52c61
< net.inet.tcp.rfc1323: 0
---
> net.inet.tcp.rfc1323: 1 70c79
< net.inet.tcp.pcbcount: 22
---
> net.inet.tcp.pcbcount: 15 77d85
< net.inet.tcp.inflight_stab: 20
120c128
< net.link.generic.system.ifcount: 8
---
> net.link.generic.system.ifcount: 3 127a136,150
> net.link.ether.bridge_cfg: > net.link.ether.bridge: 0 > net.link.ether.bridge_ipfw: 0 > net.link.ether.bridge_ipf: 0 > net.link.ether.bridge_ipfw_drop: 0 > net.link.ether.bridge_ipfw_collisions: 0 > net.link.ether.verbose: 0 > net.link.ether.bdg_split_pkts: 0 > net.link.ether.bdg_thru: 0 > net.link.ether.bdg_copied: 0 > net.link.ether.bdg_copy: 0 > net.link.ether.bdg_predict: 0 > net.link.ether.bdg_fw_avg: 0 > net.link.ether.bdg_fw_ticks: 0 > net.link.ether.bdg_fw_count: 0
|
 |  |
Требуется помощь... 06.06.03 15:07
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> В продолжение топика. > Ситуация сложиласть следующим образом: > Есть некий хост CCC, за ним сидят две машины AAA и BBB. > Если мы запустим клиент с машины AAA, то описанной в топике > проблеммы не будет. Если запусим с BBB то проблемма > возникает стабильно. > Коннект клиентов идет к некому хосту DDD. > > Было произведенно сравнение параметров ядра машин AAA и > BBB. > В листиге: AAA это < > BBB это > > Вот за это спасибо. Такому челу и помочь приятно. Вот если бы ты ещё сказал, есть ли там ipf/ipfw и привел бы их правила...
> < net.inet.ip.forwarding: 1 > --- > > net.inet.ip.forwarding: 0 Это - гейтовать или нет. Вряд ли оно.
> > net.inet.ip.dummynet.hash_size: 64 ...
> > net.inet.ip.dummynet.red_max_pkt_size: 1500 Настройки dummynet'а могут в принципе гадить если траффик идет через кривые пайпы. Это задается в правилах ipfw
> < net.inet.ip.fw.verbose_limit: 0 > --- > > net.inet.ip.fw.verbose_limit: 100 > 32c43 man ipfw, в данном случае роли не играет.
> < net.inet.ip.fw.dyn_count: 107 > --- > > net.inet.ip.fw.dyn_count: 0 > 34c45 > < net.inet.ip.fw.static_count: 34 > --- > > net.inet.ip.fw.static_count: 1 > 42,44c53 Судя по этим строчкам, на ААА стоит фаервол с 34 правилами. Кроме того там есть динамические правила. Но все это нас не колышет, так как на AAA проблем нету. На ВВВ правило одно. Что-то мне подсказывает что оно выглядит как
65535 allow ip from any to any
Выходит ipfw не гадит.
> < net.inet.ip.maxfragpackets: 79 > < net.inet.ip.maxfragsperpacket: 16 > < net.inet.ip.sendsourcequench: 0 > --- > > net.inet.ip.maxfragpackets: 632 > 52c61 не должно колыхать.
> < net.inet.tcp.rfc1323: 0 > --- > > net.inet.tcp.rfc1323: 1 > 70c79 Вот здесь может быть проблема. Я посмотрел по диагонали rfc1323 - "TCP Extensions for High Performance". Попробуй поменять этот oid
> < net.inet.tcp.pcbcount: 22 > --- > > net.inet.tcp.pcbcount: 15 > 77d85 я думаю что это кол-во PCB. Из названия. Про PCB - по моему rfc0793
> < net.inet.tcp.inflight_stab: 20 > 120c128 не знаю. надо гуглить.
> < net.link.generic.system.ifcount: 8 > --- > > net.link.generic.system.ifcount: 3 кол-во интерфейсов? не должно колыхать.
> 127a136,150 > > net.link.ether.bridge_cfg: > > net.link.ether.bridge: 0 > > net.link.ether.bridge_ipfw: 0 > > net.link.ether.bridge_ipf: 0 > > net.link.ether.bridge_ipfw_drop: 0 > > net.link.ether.bridge_ipfw_collisions: 0 > > net.link.ether.verbose: 0 > > net.link.ether.bdg_split_pkts: 0 > > net.link.ether.bdg_thru: 0 > > net.link.ether.bdg_copied: 0 > > net.link.ether.bdg_copy: 0 > > net.link.ether.bdg_predict: 0 > > net.link.ether.bdg_fw_avg: 0 > > net.link.ether.bdg_fw_ticks: 0 > > net.link.ether.bdg_fw_count: 0 настройки бриджа. появляются если скомпилить ядро с опцией BRIDGE. но так как бридж задизаблен (net.link.ether.bridge: 0), не колышет.
Резюме.
tcpdump в зубы и сравнивай две сессии. Это не так уж много работы. А если хочется легких путей - попробуй тупо поменять net.inet.tcp.rfc1323
|
 |  |  |
tcpdump :) 06.06.03 20:40
Автор: PS <PS> Статус: Elderman Отредактировано 06.06.03 23:34 Количество правок: 1
|
Наконец то я продампил пакет. К сожалению дамп сделан только на серверной стороне.
Обозначения те же: AAA - работающий хост, BBB - не работающий хост, DDD - хост сервера.
Этот дамп можно даже не смотреть, сдесь все пучком:
18:49:23.660025 AAA.4429 > DDD.4001: S 2057889375:2057889375(0) win 57344 <mss 1460> (DF)
18:49:23.660115 DDD.4001 > AAA.4429: S 1197985352:1197985352(0) ack 2057889376 win 57344 <mss 1460> (DF)
18:49:23.840403 AAA.4429 > DDD.4001: . ack 1 win 58400 (DF)
18:49:23.885531 AAA.4430 > DDD.4000: S 4081744833:4081744833(0) win 57344 <mss 1460> (DF)
18:49:23.885574 DDD.4000 > AAA.4430: S 2376670431:2376670431(0) ack 4081744834 win 57344 <mss 1460> (DF)
18:49:24.053665 AAA.4430 > DDD.4000: . ack 1 win 58400 (DF)
18:49:24.191048 AAA.4429 > DDD.4001: P 1:8(7) ack 1 win 58400 (DF)
18:49:24.198336 DDD.4000 > AAA.4430: P 1:705(704) ack 1 win 58400 (DF)
18:49:24.286047 DDD.4001 > AAA.4429: . ack 8 win 58400 (DF)
18:49:24.503242 AAA.4429 > DDD.4001: P 8:22(14) ack 1 win 58400 (DF)
18:49:24.589325 AAA.4430 > DDD.4000: . ack 705 win 58400 (DF)
18:49:24.589488 DDD.4000 > AAA.4430: P 705:2113(1408) ack 1 win 58400 (DF)
18:49:24.596050 DDD.4001 > AAA.4429: . ack 22 win 58400 (DF)
18:49:25.078410 AAA.4430 > DDD.4000: . ack 2113 win 58400 (DF)
18:50:24.057083 AAA.4429 > DDD.4001: P 22:29(7) ack 1 win 58400 (DF)
18:50:24.064235 DDD.4000 > AAA.4430: P 2113:2817(704) ack 1 win 58400 (DF)
18:50:24.156954 DDD.4001 > AAA.4429: . ack 29 win 58400 (DF)
18:50:24.258543 AAA.4429 > DDD.4001: P 29:43(14) ack 1 win 58400 (DF)
18:50:24.354875 AAA.4430 > DDD.4000: . ack 2817 win 58400 (DF)
18:50:24.355054 DDD.4000 > AAA.4430: P 2817:4225(1408) ack 1 win 58400 (DF)
18:50:24.356947 DDD.4001 > AAA.4429: . ack 43 win 58400 (DF)
18:50:24.796839 AAA.4430 > DDD.4000: . ack 4225 win 58400 (DF)
19:00:24.078217 arp who-has DDD tell relay.MY.ru
19:00:24.078238 arp reply DDD is-at ;)
19:00:24.078547 AAA.4429 > DDD.4001: P 43:50(7) ack 1 win 58400 (DF)
19:00:24.085839 DDD.4000 > AAA.4430: P 4225:4929(704) ack 1 win 58400 (DF)
19:00:24.175998 DDD.4001 > AAA.4429: . ack 50 win 58400 (DF)
19:00:24.298094 AAA.4429 > DDD.4001: P 50:57(7) ack 1 win 58400 (DF)
19:00:24.390342 AAA.4430 > DDD.4000: . ack 4929 win 58400 (DF)
19:00:24.390457 DDD.4000 > AAA.4430: P 4929:5633(704) ack 1 win 58400 (DF)
19:00:24.395998 DDD.4001 > AAA.4429: . ack 57 win 58400 (DF)
19:00:24.673881 AAA.4430 > DDD.4000: . ack 5633 win 58400 (DF)
19:05:25.150023 AAA.4429 > DDD.4001: F 57:57(0) ack 1 win 58400 (DF)
19:05:25.150098 DDD.4001 > AAA.4429: . ack 58 win 58400 (DF)
19:05:25.150192 DDD.4001 > AAA.4429: F 1:1(0) ack 58 win 58400 (DF)
19:05:25.160256 AAA.4430 > DDD.4000: F 1:1(0) ack 5633 win 58400 (DF)
19:05:25.160298 DDD.4000 > AAA.4430: . ack 2 win 58400 (DF)
19:05:25.219736 AAA.4429 > DDD.4001: . ack 2 win 58400 (DF)
19:14:11.208768 DDD.4000 > AAA.4430: F 5633:5633(0) ack 2 win 58400 (DF)
19:14:11.342270 AAA.4430 > DDD.4000: . ack 5634 win 58400 (DF)
А вот сделующий представляет интерес. К сожеленью я забыл отключить "показ портов в текстовом виде", а сокет, видимо, хватанул 1110 порт, так что с nfsd-status придеться мириться ;(
18:04:23.709008 BBB.2844 > DDD.4001: S 2139116037:2139116037(0) win 57344 <mss 1460> (DF)
18:04:23.709095 DDD.4001 > BBB.2844: S 3551804060:3551804060(0) ack 2139116038 win 57344 <mss 1460> (DF)
18:04:23.824999 BBB.2844 > DDD.4001: . ack 1 win 58400 (DF)
18:04:23.835243 BBB.nfsd-status > DDD.4000: S 2026136892:2026136892(0) win 57344 <mss 1460> (DF)
18:04:23.835289 DDD.4000 > BBB.nfsd-status: S 2228898209:2228898209(0) ack 2026136893 win 57344 <mss 1460> (DF)
18:04:24.011503 BBB.nfsd-status > DDD.4000: . ack 1 win 58400 (DF)
--- Тут коннект закончен ---
18:04:24.015590 BBB.2844 > DDD.4001: P 1:8(7) ack 1 win 58400 (DF)
18:04:24.022831 DDD.4000 > BBB.nfsd-status: P 1:705(704) ack 1 win 58400 (DF)
18:04:24.115308 DDD.4001 > BBB.2844: . ack 8 win 58400 (DF)
18:04:24.283800 BBB.2844 > DDD.4001: P 8:22(14) ack 1 win 58400 (DF)
18:04:24.375312 DDD.4001 > BBB.2844: . ack 22 win 58400 (DF)
18:04:24.387495 BBB.nfsd-status > DDD.4000: . ack 705 win 58400 (DF)
18:04:24.387658 DDD.4000 > BBB.nfsd-status: P 705:2113(1408) ack 1 win 58400 (DF)
18:04:24.656212 BBB.nfsd-status > DDD.4000: . ack 2113 win 58400 (DF)
18:05:23.988828 BBB.2844 > DDD.4001: P 22:29(7) ack 1 win 58400 (DF)
18:05:23.995944 DDD.4000 > BBB.nfsd-status: P 2113:2817(704) ack 1 win 58400 (DF)
18:05:24.086221 DDD.4001 > BBB.2844: . ack 29 win 58400 (DF)
18:05:24.493683 BBB.2844 > DDD.4001: P 29:43(14) ack 1 win 58400 (DF)
18:05:24.495710 BBB.nfsd-status > DDD.4000: . ack 2817 win 58400 (DF)
18:05:24.501346 DDD.4000 > BBB.nfsd-status: P 2817:3521(704) ack 1 win 58400 (DF)
18:05:24.586222 DDD.4001 > BBB.2844: . ack 43 win 58400 (DF)
18:05:25.210808 BBB.nfsd-status > DDD.4000: . ack 3521 win 58400 (DF)
18:05:25.210919 DDD.4000 > BBB.nfsd-status: P 3521:4225(704) ack 1 win 58400 (DF)
18:05:25.590713 BBB.nfsd-status > DDD.4000: . ack 4225 win 58400 (DF)
-- Итак, шесть пакетов ушли, теперь клиент спит 10ть минут--
18:15:24.145774 arp who-has DDD tell relay.MY.ru
18:15:24.145790 arp reply DDD is-at ;)
18:15:24.146088 BBB.2844 > DDD.4001: P 43:50(7) ack 1 win 58400 (DF)
18:15:24.153605 DDD.4000 > BBB.nfsd-status: P 4225:4929(704) ack 1 win 58400 (DF)
18:15:24.245272 DDD.4001 > BBB.2844: . ack 50 win 58400 (DF)
18:15:24.330781 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
-- А вот это уже интересно, комментарий ниже.
18:15:24.353302 BBB.2844 > DDD.4001: P 50:57(7) ack 1 win 58400 (DF)
18:15:24.445355 DDD.4001 > BBB.2844: . ack 57 win 58400 (DF)
18:15:25.395417 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:25.574337 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:15:27.695452 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:27.877684 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:15:32.095519 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:32.336842 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:15:40.695653 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:15:57.695911 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:16:29.896395 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:16:30.073253 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:17:33.897361 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:17:34.096106 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:18:37.898328 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:19:41.899293 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 1 win 58400 (DF)
18:19:42.181815 BBB > DDD: icmp: host BBB unreachable - admin prohibited filter
18:20:27.708766 BBB.2844 > DDD.4001: F 57:57(0) ack 1 win 58400 (DF)
18:20:27.708832 DDD.4001 > BBB.2844: . ack 58 win 58400 (DF)
18:20:27.708937 DDD.4001 > BBB.2844: F 1:1(0) ack 58 win 58400 (DF)
18:20:27.712845 BBB.nfsd-status > DDD.4000: F 1:1(0) ack 4225 win 58400 (DF)
18:20:27.712887 DDD.4000 > BBB.nfsd-status: . ack 2 win 58400 (DF)
18:20:27.807525 BBB.2844 > DDD.4001: . ack 2 win 58400 (DF)
18:20:45.900257 DDD.4000 > BBB.nfsd-status: P 4225:5633(1408) ack 2 win 58400 (DF)
18:20:46.137655 BBB.nfsd-status > DDD.4000: R 2026136894:2026136894(0) win 0
Итак я получил 13ю ошибку - "host unreachable - admin prohibited filter".
Почему ? Десять минут назад пакеты уходили и все было хорошо, что изменилось ?! Из-за чего такое может происходить. Почему только на BBB ?
Вообщем в моей голове kernel panic. Help !
P.S. Еще я забыл сказать, как теперь кажется, самое главное. Хоть хосты AAA и BBB сидят за CCC, но AAA имеет свой внешний адрес, т.е. использует CCC только как роутер, BBB наоборот - полностью локальная машина для сети, и использует CCC как "nat сервер". Может тут собака порылась ?
|
 |  |  |  |
tcpdump форева, однозначно 07.06.03 14:08
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> Наконец то я продампил пакет. К сожалению дамп сделан > только на серверной стороне. > > Обозначения те же: AAA - работающий хост, BBB - не > работающий хост, DDD - хост сервера. >
если ты дампил на стороне DDD, а ВВВ сидит за натом, выходит пакеты от ВВВ имеют обратный адрес CCC. Так?
> скипаем дамп...
> > Итак я получил 13ю ошибку - "host unreachable - admin > prohibited filter". > > P.S. Еще я забыл сказать, как теперь кажется, самое > главное. Хоть хосты AAA и BBB сидят за CCC, но AAA имеет > свой внешний адрес, т.е. использует CCC только как роутер, > BBB наоборот - полностью локальная машина для сети, и > использует CCC как "nat сервер". Может тут собака порылась > ? Вполне может быть.
Я не знаю, что за софтина делает нат на ССС, узнай это. Но пока могу сделать следующее предположение о принципе её работы:
Приходит Syn от ВВВ к DDD.
Создается структура примерно такого вида:
struct NATed_conn {
dword src_ip;
dword dst_ip;
word src_port;
word dst_port;
word proto;
word nated_port;//Optional если нат изменяет срц_порт
dword lastused;
}
После чего, каждый пакет проходящий через нат сравнивается по своим 5 определяющим параметрам (срц_ип,срц_порт,дст_ип,дст_порт,прото) со сриском таких структур, и если находится соответствие, хедеры переписываются, а в lastused записывается текущее время (тики, секунды, [micro|nano|pico|mega]секунды - что там у них есть). Если пакет является последним фином для тцп коннекшена, то структура удаляется (память-то не резиновая). А как быть с коннекшенами которые закончились аномально, без финов? Или с UDP коннекшенами, у которых финов вообще нету? Пишется функция remove_stale_conns , которая иногда пробегает по списку и выкидывает те структуры для которых getcurtime-lastused>N . Понятно? Или, если количество структур ограничено, и некуда вставить новую, демон находит коннекшен с самым старым lastused и выкидывает его чтобы вставить новый. Я думаю что нечто подобное произошло на машине CCC с твоим соединением. А когда оно перестало натится, пакет
18:15:24.245272 DDD.4001 > BBB.2844: . ack 50 win 58400 (DF)
пошел не к BBB а к ССС, а там ему выдали "от ворот поворот" в виде ICMP13 (это наверное фаерволл).
Выводы:
1. Узнай что за нат-демон стоит на ССС.
2. Постарайся узнать его принцип работы, если не сможешь, спроси на форуме.
3. Если проблема в нат-демоне, включи опцию SO_KEEPALIVE в клиентском сокете. Прога в сорцах, или в бинарнике? В любом случае это можно сделать. Ну вот собссно и все :)
|
 |  |  |  |  |
И в заключение... 09.06.03 13:50
Автор: PS <PS> Статус: Elderman
|
"Надежное TCP" как показала практика совсем не надежно.
На моей стороне разрыв соединения можно чекать следующим способом:
bool TCPConnector::TestSocketOn( TCPConnector* me, int read_or_write, int socket, string who, int& err )
{
int selRet;
fd_set readfds;
fd_set readfds2;
fd_set exepfds;
struct timeval tv;
who.c_str() );
FD_ZERO( &readfds );
FD_ZERO( &readfds2 );
FD_ZERO( &exepfds );
FD_SET( socket, &readfds );
FD_SET( socket, &exepfds );
FD_SET( socket, &readfds2 );
tv.tv_sec = 5;
tv.tv_usec= 0;
if( read_or_write == TCPCON_TST_S_WRITE )
selRet = select( (socket) + 1, &readfds2, &readfds, &exepfds, &tv );
else
selRet = select( (socket) + 1, &readfds, NULL, &exepfds, &tv );
if( selRet == SOCKET_ERROR )
{
// So, socket failed. It is stranger situation.
// I decide, that writer thread must be finished.
err = 1;
return false;
}
else if( selRet == 0 )
{
// Time out.
// Try againg.
err = 0;
return false;
}
else if( selRet > 0 )
{
if( FD_ISSET( socket, &exepfds ) )
{
err = 2;
return false;
}
if( read_or_write == TCPCON_TST_S_WRITE && FD_ISSET( socket, &readfds2 ))
{
char byte;
int retVal = recv( socket, &byte, 1, MSG_PEEK );
if( retVal == 0|retVal == SOCKET_ERROR|retVal == INVALID_SOCKET )
{
err = 2;
return false;
}
}
}// if
err = 0;
return true;
}
---
Но опять же - это не панацея. Я решил что лучший способ узнать о доставке пакета - это подтверждение. На каждый отправленный пакет нужно ждать подтверждение, если в течении некоторого времени его нет - считаем связь разорванной. На это все и было переписанно (счастливые, у вас были выходные... :( )
Кстати зашел вчера вечерком в один книждый магазинчик, там стоит книжечка по TCP/IP, желтенькая такая, трехтомная. Нашел нужную тему, а там русским по белому написанно, что для надежной доставки по TCP нужно самому реализовывать пакеты подтверждения. О как ! (от себя добавлю - на это можно, конечно, забить. И в большитстве случаев все работать будет. Но рано или поздно софт нарвется на то состояние в сети, о котором вся эта ветка ).
|
 |
Еще одна фигня с send 04.06.03 19:08
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> Proto Recv-Q Send-Q Local Address Foreign Address > (state) > tcp4 0 0 xxxx.4001 yyyy.1225 ESTABLISHED > tcp4 0 1220 xxxx.4000 yyyy1224 ESTABLISHED > > В сокете на отправку лежат 1220 байт, и не уходят ! > Вот так, send() мне не возвращает -1. Типа все отправил, > все ок. А на самом деле данные лежат в очереди, и их не > могут получить. > > Кто с такой фигней встречался ? Из-за чего может быть ? Первое что приходит в голову - нет места в окне TCP сессии. То есть - не пришел подтверждающий ACK на пакет № N а мы уже заслали N+K пакетов вперед. Подробности давай, посмотрим.
Вот например вопросы:
1. Нельзя ли получить tcpdump лог сессии.
2. Что значит "данные лежат в сессии"? Сколько они там лежат, погибает ли сокет по таймауту, жив ли удаленный хост, удаленный процесс.
|
 |  |
Ага, дело было так 04.06.03 19:27
Автор: PS <PS> Статус: Elderman
|
1. Засылаем пакет (610 байт)
2. Он лежит в буфере сокета (видимо ACK действительно нет. почему ?)
3. Засылаем второй пакет (610 байт). Теперь у нас там лежит 1220. Жду...
4. Минут через 15 говорю netstat - опа ! А соединения уже нет. Кстати, на другой стороне (в другом городе нашей необъятной Родины) netstat утверждает что ESTABLISHED - весело.
5. Пытаюсь записать туда третий пакет. И только сейчас получаю облом в виде любимого SIGPIPE ! Ну слава богу, хоть так просигнализировал.
Итого: два пакета якобы ушли, на самом деле были потерянны. И еще один явно не ушел.
И как с этим работать ?
|
 |  |  |
Немножко уточним. 04.06.03 19:41
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
1. Это произошло один раз, или это регулярные/постоянные траблы?
2. Если удастся повторить - сможешь снять tcpdump?
3. Хоть что-нибудь проходит по этому соединению, или фигня начинается при первых же 1220 байтах?
4. Кстати, может говорить не бАйты а байтА, типа как профессиональный жаргон (мы говорим не штОрмы а штормА), но это так, slightly offtopic.
5. Остальные ТСР соединения между этими двумя серверами - работают?
|
 |  |  |  |
Немножко уточним. 04.06.03 19:50
Автор: PS <PS> Статус: Elderman
|
> 1. Это произошло один раз, или это регулярные/постоянные > траблы?
Регулярные.
> 2. Если удастся повторить - сможешь снять tcpdump?
Если ничего другого не поможет - то придется.
> 3. Хоть что-нибудь проходит по этому соединению, или фигня > начинается при первых же 1220 байтах?
Так, сначала (после accept) все идет просто отлично. Потом я иду курить, чел на другой стороне идет курить... мы курим где то 20 минут. И вот после такого таймаута send прекращает что либо посылать. (мистика, борьба FreeBSD с табакокурением)
> 4. Кстати, может говорить не бАйты а байтА, типа как > профессиональный жаргон (мы говорим не штОрмы а штормА), но > это так, slightly offtopic.
No comments.
> 5. Остальные ТСР соединения между этими двумя серверами - > работают?
Есть еще одно соединение, на другой стороне в него делают send, я делаю только recv. Оно работает стабильно.
|
 |  |  |  |  |
а если чел с той стороны через 20 мин пакет пошлет с его стороны соединение рвется? (RST) 07.06.03 14:34
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
 |  |  |  |  |
Немножко уточним. 04.06.03 19:57
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
> > 2. Если удастся повторить - сможешь снять tcpdump? > > Если ничего другого не поможет - то придется. Слушай, этож совсем нетрудно. По крайней мере на твоей стороне. Я всегда это делаю одним из первых шагов.
> > > 3. Хоть что-нибудь проходит по этому соединению, или > фигня > > начинается при первых же 1220 байтах? > > Так, сначала (после accept) все идет просто отлично. Потом > я иду курить, чел на другой стороне идет курить... мы курим > где то 20 минут. И вот после такого таймаута send > прекращает что либо посылать. (мистика, борьба FreeBSD с > табакокурением) > О ! После таймаута. А что если я спрошу - есть ли между вами firewall'ы? И есть ли там правила вроде FreeBSDшных keep-sate? Мне кажется, что это могло бы стать причиной. Что если включить SO_KEEPALIVE на сокете?
|
|
|