Средства и методы разработки

Автор не просто так сказал про теорию массового обслуживания. Допустим, если в терминах теории массового обслуживания, то поступающие данные -- это внешние события или заявки. Они как-то обрабатываютя у тебя процессором и поступают на вывод. Обработка каждой заявки/события занимает какое-то время и в это время другие события/заявки не обрабатываются, а задерживаются в очереди (твой FIFO буфер). В таких условиях задержка в обработке каждой поступившей заявки/события имеет распределение похожие на экспоненциальное, пусть меня поправят, я не слишком знаком, даже скорей не знаком с теорией. Но у этого распределения есть пик где-то в начале ("средняя глубина очереди") и длинный-длинный хвост. И если ты 5 минут смотрел на светодиод, то хвоста, который редкий одиночный пик в глубине очереди, мог и не заметить. А в работе потом этот пик (потребления памяти, размера очереди) может случаться изредка и рушить процесс, программу, вызывать отказ в оборудовании. Я приаттачил картинку, она получена с этого сайта: http://r1ban.ru/likbez/TMO.htm -- это симуляция проведённая за некоторое длительное время. Прекрасно видно длинный хвост в графике (жёлтом), и также, что TWmax (максимальное время ожидания) сильно больше среднего. И что глубина очереди которая обычно очень низкая иногда, редко, значит, вырастает до значительных размеров. Аналогия -- волны-солитоны в море. Могут топить корабли. Но обычно взглядом не наблюдаемы и можно заключить, при недостаточном интервале наблюдения, что их не существует вовсе. Какие из этого можно сделать выводы: методика со светодиодом ОПАСНАЯ. Следует предусмотреть какой-то анализ или симуляцию обработки поступающего потока событий (байт, пакетов из сети...) и выбрать буфер с запасом. Потому, что может сложиться такая комбинация событий, которая хоть и не наблюдаема на коротком интервале времени, на длительном может встретиться и приводить к переполнению буфера. Keywords: java applet, simulation, erlang.