От вопроса про жену/девушку уклонились? Слишком неудобен для ответа по выдержанной линии?

К чему этот коммент? Речь и шла о том, что в странах третьего мира инвалиды наврядли могут позволить себе читалки.

Я про то, что студенты разрабатывают инвалидные кресла для стран третьего мира, а те, кто ворочает миллиардами, всё анонсируют новые читалки. Образно, конечно.

Массачусетский Технологический Институт анонсировал инвалидное кресло повышенной проходимости для бедных.

И чуть ниже по Хабру:

Компания ASUS анонсировала на CeBIT 2010 свою новую читалку DR-900.

Не знаю почему, но стало как-то печально и грустно…

Вам нужно, чтобы люди браузером пользовались, или статистику загрузок набить?

Ностальгия. Скупая мужская скатилась по небритой щеке.

Сегодня попробуем померять все это дело.

Скорее это пережитки не так давно покинутой предыдущей конторы с ее тоннами документации по оформлению кода. Если не сложно, укажите на конкретные места и лучшие решения — учиться, как говорится, никогда не поздно.

Вероятность того, что значение нового Guid будет содержать одни нули или окажется равным какому-либо другому Guid, предельно мала. ©MSDN

Предельно мала, но все-таки не равна нулю.

О готовых решениях думал, читал. Однако Comet настолько заинтересовал, что дико захотелось реализовать самому. Кое-что из этого желания, как видим, все-таки вышло :) Что касается ресурсов, какие именно вы имеете в виду?

Как раз вчера пришла спецификация, сегодня начинаем наращивать на этот Comet-скелет сухожилия и мышцы. Предварительные результаты описаны в этом комментарии. Как дойдет дело до масштабных испытаний и стрессовых нагрузок, отпишу дополнительно.

Это то, что вы ищите?

Использование события unload для определения дисконнекта клиента является, наверное, самым очевидным решением для решения данной проблемы. Минус, правда, тоже очевиден — реконнект клиента при постбэках. Интересно узнать, как Вы решили эту проблему?

Ориентировано на широкий (в перспективе даже очень широкий) круг пользователей, однако, как я уже писал, масштабный стресс-тест такого подхода провести пока не было возможности (честно говоря, мы пока не нашли подходящий способ, поэтому я в конце статьи просил поделиться наработками, если кто-то сталкивался с подобным). Лично я проверял на 25 клиентах (и сервер, и клиенты были на одной машине) при пушинге частотой до десятка раз в секунду, при этом нагрузка на CPU была настолько мизерной, что стандартным Task Manager'ом ее даже невозможно было разглядеть.

Добавил в конец статьи ссылку на архив с исходниками и кратенький мануал.

Понимаете, суть технологии Comet заключается в передаче данных клиентам по инициативе сервера, а не самих клиентов. В идеале это постоянное соединение между клиентом и сервером, и именно сервер, когда считает нужным (по возникновению какого-то серверного события, например), выдает клиенту данные. В том же примере из MSDN, который вы привели, отнюдь не сервер решает, когда данные должны быть отправлены клиенту, это решает клиент путем асинхронного вызова метода веб-сервиса. Таким образом, чтобы обеспечить обновление данных на клиенте в режиме близком к режиму реального времени, вам придется постоянно вызывать данный метод (в частности, по таймеру), проверяя, есть ли серверу чем поделиться. Недостатки такого подхода уже описаны в первом абзаце статьи.

Рад, что чем-то смог Вам помочь.