У меня такое впечатление, что на самом деле истинный софтописатель - это как раз Вы, он же Гегель.
3igzag, это ошибочный вывод... Если честно, не могу понять даже, на чем это базируется: ни в одном своем посте на многих форумах вроде не давал повода идентифицировать себя с кем либо. Да и концепция "инь-янь" мне не характерна... Тем более, есть люди, знающие как меня, так и ув. buxarina лично, так что как в анекдоте получается: Карл Маркс и Фридрих Енгельс - не муж и жена, а четыре разных человека
А что касается выводов по эксперименту, то вовсе это не антиреклама. Лично я преследую только академический интерес. На абсолютную "чистоту" не претендую, а углюбляться не стал, памятуя пост tedim на альфасате: P.S. Может, давайте говорить немного проще, зато людям станет много приятнее
Но если людям все же интересно, попробую поточнее сформулировать мысль...
Т.к. меня достаточно давно интересует природа потерь в CS с целью их минимизации, и так как при тестировании эво-модема визуально наблюдались затыки, решил попытаться ориентировочно установить локализацию потерь (сервер, аплинк, даунлинк).
Использовались эво-модемы с тестовым софтом, работающие через мой софтовый транслятор evoserv (он же писал лог) с опенами ф300. Работали две такие связки, географически расположенные в одном населенном пункте. Условия приема почти одинаковые (dish 0.9 фокус).
Писалось два лога Кинохит в течение часа, тест производился около 19 вечера, хотя и не пойму, какое значение это имеет.
Смысл экперимента заключался в том, чтобы определить, какой процент от общего числа потерянных ДВ составляют потери одного и того же ДВ в обоих системах одновременно. Такие потери скорее всего не спонтанны, а сгенерированы или на аплинке или не сервере, но не на даунлинке и не в трансляторе.
Далее попытался из этого числа потерь отсеять потери аплинка, оставив только серверные. Тут уж эксперимент был совсем не чистый, но хоть ориентировочно: размер удп-пакетов определил как MTU (думаю, каждый ДВ вы не передаете поотдельности) для PlanetSky (тоже нет уверенности, что этот провайдер использован, догадки...), послав 100 пакетов, определил общий процент потерь (получилось 2, что мало),так что отсюда вывод - практически все совпадающие в обоих системах потери - результат неотправленных сервером ДВ.
И это не критика ни сервера, ни системы в целом, просто факт. И какая разница, тестовая версия или коммерческая: на сервере ни карт не добавится, ни есм стабильнее поступать не станут...
А повторить эксперимент я предлагал в том же виде, но с жпрс-шарингом, пытаясь аналогичным способом доказать ведущую роль потерь сервера по сравнению с потерями транспорта (не в тему, но как ответ на критику ситемы на Cименсах). И опять сюда же - gsm gprs имеет свои механизмы компенсации потерь и гарантии доставки на уровне транспорт-протокола. Проверить можно так: поднимите жпрс, отправте один удп на сервер (для создания ассоциации портов), затем экранируйте телефон от сигнала, и отправьте в обратку пакет с сервера. Затем снимите экран и дождитесь регистрации телефона в сети. Сразу же получите пакет, буферизированный в системе (сроков и размера буферизации не уточнял).
А практически - жпрс способна давать чрезвычайно качественный сервис CS по удп-протоколу, конечно, при хорошем сервере, не хуже выделенки. Как результат нашей дискусси о NewCAMD потратил почти месяц, но реализовал этот протокол на PIC18F1320. Пришлось выруливать логику своего сркета тсп, часами сидя за нетвьювером и моделируя потери как туда, так и обратно, как при ровном просмотре, так и при переключении между каналами с разной длиной есм (сбой SEQ - ACQ) и т.п. И опять таки вывод - на сколько удп рациональнее, проще и стабильнее для CS! И при верном алгоритме посылки повторных заросов - качественнее!