Forum Replies Created
-
AuthorPosts
-
WinpkFilter 3.2.14.1 update:
- Receive Segment Coalescing (RSC) task offload issue fixed (could cause packet loss and performance degradation for some network interfaces)
- Added hardware filter change notification event API SetHwPacketFilterEvent
If you are eligible for a free update, please send the following details to support@ntkernel.com tо receive an update instruction:
Your order ID.
An approximate date of purchasing.Windows Packet Filter 3.2.9.1 update:
- Added extended validation for the parameters passed from client application to WinpkFilter drivers. Some additional related information is available here
If you are eligible for a free update, please send the following details to support@ntkernel.com tо receive an update instruction:
Your order ID.
An approximate date of purchasing.У меня под рукой была чистая Windows 10 x64 с тестовой сборкой драйвера 3.2.10.2 (доступна по ссылке выше). Готовый бинарник ebridge.exe взял с github. Так как это laptop, то гигабитный порт всего один, в качестве второго сетевого интерфейса использовался USB Ethernet адаптер ‘ASIX AX88772B USB2.0 to Fast Ethernet’. Соответственно пропускная способность моста ограничена 100 Mbps, в остальном все аналогично:
LAN <-1Gbps-> [192.168.1.238 | EBRIDGE | 192.168.1.247] <-100Mbps-> [192.168.1.220]
Сервер на 192.168.1.220, клиент поочередно с 192.168.1.238 и 192.168.1.247 в прямом и обратном порядке:
PS C:\Users\vadim\Desktop\iperf3> ./iperf3.exe -c 192.168.1.220
Connecting to host 192.168.1.220, port 5201
[ 4] local 192.168.1.238 port 50273 connected to 192.168.1.220 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.5 MBytes 96.4 Mbits/sec
[ 4] 1.00-2.01 sec 11.4 MBytes 94.9 Mbits/sec
[ 4] 2.01-3.00 sec 11.2 MBytes 94.9 Mbits/sec
[ 4] 3.00-4.01 sec 11.4 MBytes 94.8 Mbits/sec
[ 4] 4.01-5.00 sec 11.2 MBytes 95.0 Mbits/sec
[ 4] 5.00-6.01 sec 11.4 MBytes 94.8 Mbits/sec
[ 4] 6.01-7.01 sec 11.4 MBytes 95.0 Mbits/sec
[ 4] 7.01-8.00 sec 11.2 MBytes 95.0 Mbits/sec
[ 4] 8.00-9.00 sec 11.2 MBytes 94.8 Mbits/sec
[ 4] 9.00-10.01 sec 11.4 MBytes 94.9 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 113 MBytes 95.1 Mbits/sec sender
[ 4] 0.00-10.01 sec 113 MBytes 95.0 Mbits/sec receiveriperf Done.
PS C:\Users\vadim\Desktop\iperf3> ./iperf3.exe -c 192.168.1.220 -R
Connecting to host 192.168.1.220, port 5201
Reverse mode, remote host 192.168.1.220 is sending
[ 4] local 192.168.1.238 port 50276 connected to 192.168.1.220 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.7 MBytes 97.9 Mbits/sec
[ 4] 1.00-2.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 2.00-3.00 sec 11.3 MBytes 94.6 Mbits/sec
[ 4] 3.00-4.00 sec 11.3 MBytes 94.8 Mbits/sec
[ 4] 4.00-5.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 5.00-6.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 6.00-7.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 7.00-8.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 8.00-9.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 9.00-10.00 sec 11.3 MBytes 94.7 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 114 MBytes 95.2 Mbits/sec sender
[ 4] 0.00-10.00 sec 114 MBytes 95.2 Mbits/sec receiveriperf Done.
PS C:\Users\vadim\Desktop\iperf3> ./iperf3.exe -c 192.168.1.220 -B 192.168.1.247
Connecting to host 192.168.1.220, port 5201
[ 4] local 192.168.1.247 port 50281 connected to 192.168.1.220 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 11.6 MBytes 96.6 Mbits/sec
[ 4] 1.01-2.00 sec 11.2 MBytes 95.0 Mbits/sec
[ 4] 2.00-3.01 sec 11.4 MBytes 94.7 Mbits/sec
[ 4] 3.01-4.00 sec 11.2 MBytes 95.1 Mbits/sec
[ 4] 4.00-5.01 sec 11.4 MBytes 94.8 Mbits/sec
[ 4] 5.01-6.00 sec 11.2 MBytes 95.0 Mbits/sec
[ 4] 6.00-7.01 sec 11.4 MBytes 94.8 Mbits/sec
[ 4] 7.01-8.00 sec 11.2 MBytes 94.9 Mbits/sec
[ 4] 8.00-9.01 sec 11.4 MBytes 95.0 Mbits/sec
[ 4] 9.01-10.00 sec 11.2 MBytes 95.0 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 113 MBytes 95.1 Mbits/sec sender
[ 4] 0.00-10.00 sec 113 MBytes 95.0 Mbits/sec receiveriperf Done.
PS C:\Users\vadim\Desktop\iperf3> ./iperf3.exe -c 192.168.1.220 -B 192.168.1.247 -R
Connecting to host 192.168.1.220, port 5201
Reverse mode, remote host 192.168.1.220 is sending
[ 4] local 192.168.1.247 port 50283 connected to 192.168.1.220 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.7 MBytes 98.0 Mbits/sec
[ 4] 1.00-2.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 2.00-3.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 3.00-4.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 4.00-5.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 5.00-6.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 6.00-7.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 7.00-8.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 8.00-9.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 9.00-10.00 sec 11.3 MBytes 94.6 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 114 MBytes 95.2 Mbits/sec sender
[ 4] 0.00-10.00 sec 114 MBytes 95.2 Mbits/sec receiveriperf Done.
Сервер на 192.168.1.238 и 192.168.1.247, клиент поочередно на каждый из адресов сервера в прямом и обратном порядке:
PS D:\iperf3> ./iperf3.exe -c 192.168.1.238
Connecting to host 192.168.1.238, port 5201
[ 4] local 192.168.1.220 port 2182 connected to 192.168.1.238 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.5 MBytes 96.3 Mbits/sec
[ 4] 1.00-2.01 sec 11.4 MBytes 94.7 Mbits/sec
[ 4] 2.01-3.01 sec 11.2 MBytes 94.7 Mbits/sec
[ 4] 3.01-4.00 sec 11.2 MBytes 94.7 Mbits/sec
[ 4] 4.00-5.01 sec 11.4 MBytes 94.7 Mbits/sec
[ 4] 5.01-6.00 sec 11.1 MBytes 94.0 Mbits/sec
[ 4] 6.00-7.00 sec 11.4 MBytes 95.4 Mbits/sec
[ 4] 7.00-8.01 sec 11.4 MBytes 94.7 Mbits/sec
[ 4] 8.01-9.00 sec 11.1 MBytes 93.9 Mbits/sec
[ 4] 9.00-10.00 sec 11.2 MBytes 94.5 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 113 MBytes 94.8 Mbits/sec sender
[ 4] 0.00-10.00 sec 113 MBytes 94.7 Mbits/sec receiveriperf Done.
PS D:\iperf3> ./iperf3.exe -c 192.168.1.247
Connecting to host 192.168.1.247, port 5201
[ 4] local 192.168.1.220 port 2185 connected to 192.168.1.247 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.5 MBytes 96.4 Mbits/sec
[ 4] 1.00-2.01 sec 11.4 MBytes 94.6 Mbits/sec
[ 4] 2.01-3.00 sec 11.1 MBytes 94.1 Mbits/sec
[ 4] 3.00-4.00 sec 11.2 MBytes 94.3 Mbits/sec
[ 4] 4.00-5.01 sec 11.5 MBytes 95.7 Mbits/sec
[ 4] 5.01-6.01 sec 11.2 MBytes 94.7 Mbits/sec
[ 4] 6.01-7.00 sec 11.2 MBytes 94.7 Mbits/sec
[ 4] 7.00-8.01 sec 11.4 MBytes 94.7 Mbits/sec
[ 4] 8.01-9.01 sec 11.1 MBytes 93.8 Mbits/sec
[ 4] 9.01-10.00 sec 11.4 MBytes 95.6 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 113 MBytes 94.9 Mbits/sec sender
[ 4] 0.00-10.00 sec 113 MBytes 94.7 Mbits/sec receiveriperf Done.
PS D:\iperf3> ./iperf3.exe -c 192.168.1.238 -R
Connecting to host 192.168.1.238, port 5201
Reverse mode, remote host 192.168.1.238 is sending
[ 4] local 192.168.1.220 port 2187 connected to 192.168.1.238 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.7 MBytes 98.0 Mbits/sec
[ 4] 1.00-2.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 2.00-3.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 3.00-4.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 4.00-5.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 5.00-6.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 6.00-7.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 7.00-8.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 8.00-9.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 9.00-10.00 sec 11.3 MBytes 94.9 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 114 MBytes 95.3 Mbits/sec sender
[ 4] 0.00-10.00 sec 114 MBytes 95.3 Mbits/sec receiveriperf Done.
PS D:\iperf3> ./iperf3.exe -c 192.168.1.247 -R
Connecting to host 192.168.1.247, port 5201
Reverse mode, remote host 192.168.1.247 is sending
[ 4] local 192.168.1.220 port 2189 connected to 192.168.1.247 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.7 MBytes 98.1 Mbits/sec
[ 4] 1.00-2.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 2.00-3.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 3.00-4.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 4.00-5.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 5.00-6.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 6.00-7.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 7.00-8.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 8.00-9.00 sec 11.3 MBytes 94.9 Mbits/sec
[ 4] 9.00-10.00 sec 11.3 MBytes 94.9 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 114 MBytes 95.4 Mbits/sec sender
[ 4] 0.00-10.00 sec 114 MBytes 95.4 Mbits/sec receiveriperf Done.
И еще одна конфигурация, iperf сервер на 192.168.1.220, мост только перекладывает пакеты:
[192.168.1.25] <-1Gbps-> [192.168.1.238 | EBRIDGE | 192.168.1.247] <-100Mbps-> [192.168.1.220]
PS D:\tools\iperf3> ./iperf3 -c 192.168.1.220
Connecting to host 192.168.1.220, port 5201
[ 4] local 192.168.1.25 port 18031 connected to 192.168.1.220 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 11.6 MBytes 96.4 Mbits/sec
[ 4] 1.01-2.00 sec 11.2 MBytes 95.1 Mbits/sec
[ 4] 2.00-3.00 sec 11.2 MBytes 94.8 Mbits/sec
[ 4] 3.00-4.01 sec 11.4 MBytes 94.9 Mbits/sec
[ 4] 4.01-5.00 sec 11.2 MBytes 94.9 Mbits/sec
[ 4] 5.00-6.01 sec 11.4 MBytes 94.9 Mbits/sec
[ 4] 6.01-7.01 sec 11.4 MBytes 94.9 Mbits/sec
[ 4] 7.01-8.00 sec 11.2 MBytes 95.0 Mbits/sec
[ 4] 8.00-9.00 sec 11.2 MBytes 94.8 Mbits/sec
[ 4] 9.00-10.00 sec 11.2 MBytes 94.4 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 113 MBytes 95.0 Mbits/sec sender
[ 4] 0.00-10.00 sec 113 MBytes 95.0 Mbits/sec receiveriperf Done.
PS D:\tools\iperf3> ./iperf3 -c 192.168.1.220 -R
Connecting to host 192.168.1.220, port 5201
Reverse mode, remote host 192.168.1.220 is sending
[ 4] local 192.168.1.25 port 18042 connected to 192.168.1.220 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.7 MBytes 98.0 Mbits/sec
[ 4] 1.00-2.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 2.00-3.00 sec 11.3 MBytes 94.8 Mbits/sec
[ 4] 3.00-4.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 4.00-5.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 5.00-6.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 6.00-7.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 7.00-8.00 sec 11.3 MBytes 94.6 Mbits/sec
[ 4] 8.00-9.00 sec 11.3 MBytes 94.7 Mbits/sec
[ 4] 9.00-10.00 sec 11.3 MBytes 94.7 Mbits/sec
– – – – – – – – – – – – – – – – – – – – – – – – –
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 114 MBytes 95.2 Mbits/sec sender
[ 4] 0.00-10.00 sec 114 MBytes 95.2 Mbits/sec receiveriperf Done.
Во всех случая производительность одинаковая и упирается в пропускную способность Fast Ethernet адаптера.
Похоже на то что проблема специфична для вашего стенда, сложно сказать в железе ли дело или в установленном софте, стоит попробовать собрать еще один и все перепроверить.
В дампах я проблем не вижу, TCP сессия идет вполне успешно, значит дело скорей всего в самом приложении моста. Ethernet Bridge был написан для демонстрации, я не тестировал его производительность, но 2.5 Mbps выглядит слабовато. Поскольку на производительность может влиять множество факторов, несколько вопросов:
- Это полностью оригинальный Ethernet Bridge или в него добавлен какой-то еще код? Даже одна строка может иметь значение…
- На 64-битной системе используется 64-битная сборка Ethernet Bridge? Использование 32-битной сборки на 64 битной системе не лучшим образом сказывается на производительности.
- Используется Release build?
- Хотелось бы увидеть загрузку ядер CPU и загрузку сети по обоим хостам.
Возможно возникает эффект циклического рероутинга, когда один и тот же пакет рероутится на одном и том же интерфейсе пока не истечет TTL. Это несложно проверить посмотрев снифером трафик на проседающем интерфейсе. Обычно для того чтобы избавиться от этого эффекта достаточно отключить IP forwarding. Стандартный инсталлятор для WinpkFilter включает IP forwarding в реестре если при установке выбран Internet Gateway. Попробуйте отключить (если включен), перезагрузиться и протестировать еще раз. Если не поможет то хотелось бы взглянуть на то что покажет сетевой сниффер.
IPEnableRouter
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type Range Default value
REG_DWORD 0 | 1 0
DescriptionDetermines whether the system routes IP packets to the networks to which it is connected.
Value Meaning
0 The system routes IP packets.
1 IP packets are not routed.1) Не знаю почему, но если установить событие через SetHwPacketFilterEvent, то мост перестает работать или работает так медленно, что связь нестабильная (не знаю точно).
Ага, ну тут ошибка в NDISAPI закралась, хотя я же советовал не использовать WOW64… Но, есть и плюс, нашлась опечатка (IOCTL_NDISRD_SET_EVENT вместо IOCTL_NDISRD_SET_ADAPTER_HWFILTER_EVENT для WOW64). Неверный IOCTL сбрасывал событие для адаптера…
Обновил DLL: https://1drv.ms/u/s!AqMWR3uDO7eagZU81aJhHgoGudFVbg
#ifndef _WIN64 if (m_bIsWow64Process) { ADAPTER_EVENT_WOW64 AdapterEvent64; AdapterEvent64.hAdapterHandle.QuadPart = m_Handle32to64[(unsigned)AdapterEvent.hAdapterHandle].QuadPart; AdapterEvent64.hEvent.HighPart = 0; AdapterEvent64.hEvent.LowPart = (ULONG_PTR)AdapterEvent.hEvent; bIOResult = DeviceIoControl( IOCTL_NDISRD_SET_EVENT, &AdapterEvent64, sizeof(ADAPTER_EVENT_WOW64), NULL, 0, NULL, // Bytes Returned NULL ); } else #endif //_WIN64 { bIOResult = DeviceIoControl( IOCTL_NDISRD_SET_ADAPTER_HWFILTER_EVENT, &AdapterEvent, sizeof(ADAPTER_EVENT), NULL, 0, NULL, // Bytes Returned NULL ); }
2) Иногда сбивается режим фильтра с NDIS_PACKET_TYPE_PROMISCUOUS на значение 0, но мост все равно работает: пинг до интернета и до локальных компьютеров идет норм.
Ноль – это не валидный фильтр, скорей всего получить фильтр не удалось.
NDISAPI в сборке собрана с поддержкой UNICODE, так что, на выбор, надо или включить UNICODE для вашего приложения или пересобрать NDISAPI без UNICODE.
И второе, для 64-битной системы стоит все-таки использовать 64-битное приложение (и соответственно 64-битную сборку DLL). Не будет потерь производительности при конверсии структур для 64-битного драйвера.
Добавил, так же немного обновил реализацию, добавил инсталлятор и подписал все драйвера.
Для тестов руки не дошли, так что если не затруднит – напишите как отрабатывает новое событие.
Кастомная сборка делается для клиента с новым имененм драйвера и рядом других параметров.
Но если очень хочется попробовать, то почему нет. По ссылке тестовая сборка, заранее предупреждаю, что не проверял работоспособность нового API:
- бинарники драйверов для Vista/7/8. Под десятку сложнее процедура подписи, поэтому не включен. Драйвера можно поставить вручную через свойства сетевого соединения.
- бинарники и исходный код для NDISAPI.DLL с новой функцией
Технически это может сделать любой драйвер сетевого протокола, в том числе TCP/IP или Winpcap (если использовался Wireshark).
В принципе, поскольку драйвер фильтрует все NDIS запросы к сетевому интерфейсу, то можно либо добавить notification event на изменение фильтра, либо не позволять кому бы то ни было менять фильтр установленный через winpkfilter. Можно добавить такое к custom сборке…
И еще один момент, любое другое приложение обращающееся к драйверу может поставить свои события на пакеты и мост перестанет их получать. Например, достаточно запустить стандартный passthru на одном из интерфейсов моста, чтобы последний перестал нормально работать. В целом для production стоит ограничить доступ к драйверу (для демо версии это неудобно).
Маловато конечно информации, чтобы делать какие-то выводы. Во-первых, какие интерфейсы включены в мост? Два обычных Ethernet 802.3?
Для начала стоит посмотреть в отладчике чем заняты рабочие потоки после того как мост перестает работать. Для наглядности я бы добавил консольный вывод в рабочие потоки (получил пакеты -> переслал пакеты). Сразу будет понятно какой поток заснул или вообще вышел.
Например, если мост перестал функционировать, но при этом потоки продолжают получать и перекладывать пакеты и оба сетевых интерфейса сами по себе работают нормально (пингают хосты в подключенных сетях), то возможно что-то сбрасывает promiscuous фильтр на одном или на обоих интерфейсах. Это несложно проверить, прочитав текущий фильтр, как, впрочем, несложно и поправить, восстановив promiscuous.
If I’m not mistaken Internet Gateway uses single thread to send/receive packets from both adapters (LAN and WAN) waiting with WaitForMultipleObjects an adapter associated event objects.
So, in order to implement bandwidth management I’d advise launching two threads instead, one per network interface, each waiting with WaitForSingleObject on associated event. This way you should be able to delay packets for the selected network adapter without affecting the second one. Just note to take care about threads synchronization when accessing shared data. You can use Ethernet Bridge source for the reference for thread per network adapter model.
В общем да, рестартовать мост имеет смысл если произошли изменения в используемых интерфейсах, остальные изменения можно игнорировать. Внутренне HANDLE сетевого адаптера – это указатель на структуру в ядре, она удаляется только при удалении адаптера из системы, то есть HANDLE может изменится только если адаптер был удален и снова добавлен.
Единственно, если 32-битное приложение работает с драйвером на 64-битной системе, то NDISAPI включает дополнительный уровень трансляции для хэндлов (из 32 в 64 битные) и на постоянство хэндлов полагаться нельзя, 32-битные хэндлы в этом случае – индексы в массиве 64-битных.
Судя по симптомам, скорей всего дело в том, что один из интерфейсов переподключается в процессе работы. Это поведением можно симитировать сделав disable/enable одной из сетевых карт моста в процессе работы.
Простоты ради Ethernet Bridge не обрабатывает изменения сетевой конфигурации. Нужно бы добавить мониторинг изменений доступных интерфейсов (SetAdapterListChangeEvent) и останавливать/перезапускать мост когда один из адаптеров “уходит”/”возвращается”.
Как-нибудь доработаю на досуге, по хорошему для длительной работы из него вообще предпочтительней сделать сервис.
-
AuthorPosts