Метатрейдер считает весь свой полезный трафик. Но в реальности полезный трафик дополняется сетевой подсистемой служебным трафиком. На каждый пакет данных служебный трафик составляет около 50 байт. То есть, даже если пересылать 1 байт полезного трафика в одном пакете, в реальности будет передан 51 байт. МетаТрейдер не знает, как фактически организуется передача данных, так как он не контролирует саму передачу пакетов.
Служебный трафик малозначителен, когда идет массовая прокачка больших кусков данных (файлы по FTP, тяжелые HTML страницы и тд). Там обычно на 1.5 кб полезных данных идет 50 байт служебной обертки.
Особенность рилтаймовых соединений (торговые терминалы) в том , что очень часто посылаются очень мелкие (10-20 байт) пакеты тиковых данных. На них перерасход служебного трафика просто огромен. Кроме того, на мелких посылках получается большой обратный служебный поток(вообще без полезных данных - там только служебные подтверждения) в виде подтверждений о удачном получении очередного пакета.
Проблема чрезмерного служебного трафика на мелких пакетах - это концептуальная особенность TCP/IP протокола. Тут уже ничего не поделаешь.
Служебный трафик малозначителен, когда идет массовая прокачка больших кусков данных (файлы по FTP, тяжелые HTML страницы и тд). Там обычно на 1.5 кб полезных данных идет 50 байт служебной обертки.
Особенность рилтаймовых соединений (торговые терминалы) в том , что очень часто посылаются очень мелкие (10-20 байт) пакеты тиковых данных. На них перерасход служебного трафика просто огромен. Кроме того, на мелких посылках получается большой обратный служебный поток(вообще без полезных данных - там только служебные подтверждения) в виде подтверждений о удачном получении очередного пакета.
Проблема чрезмерного служебного трафика на мелких пакетах - это концептуальная особенность TCP/IP протокола. Тут уже ничего не поделаешь.
Renat, спасибо за исчерпывающий ответ, подтвердивший мои предположения!
Renat :
очень мелкие (10-20 байт) пакеты тиковых данных. На них перерасход служебного трафика просто огромен. Кроме того, на мелких посылках получается большой обратный служебный поток(вообще без полезных данных - там только служебные подтверждения) в виде подтверждений о удачном получении очередного пакета.
очень мелкие (10-20 байт) пакеты тиковых данных. На них перерасход служебного трафика просто огромен. Кроме того, на мелких посылках получается большой обратный служебный поток(вообще без полезных данных - там только служебные подтверждения) в виде подтверждений о удачном получении очередного пакета.
А сколько байт занимает это служебное подтверждение?
Просто хотелось бы количественно определить соотношение входящего и исходящего трафика.
И еще
Какие будут предложения по оценке входящего трафика ? Например такой метод: количество полученных котировок x размер пакета (10-20 байт полезной+50 байт служебной инфы) Годится?
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В счётчике естественно был сделан фильтр на подсчёт трафика между компьютером и сервером брокера по IP адресу. В результате за период почти сутки имеем показания в МТ4 202/36kb и показания SoftPerfect Traffic Meter: Received 1,19 МБ, Sent 1,00 МБ, Total 2,19МБ. А ведь провайдер выставит счёт за GPRS скорее всего по значению Total 2,19МБ, а не по значению МТ4 202+36=238kb?
Разъясните, пожалуйста, ситуацию со счётчиком в МТ4.