Хотя нет, поспешил с выводами. Насчёт мотивации я тоже не согласен, никогда не ощущал себя обиженным за то, что нетехнические посты набирают больше плюсов — потому как понимаю, что технические посты оценивают специалисты в данной конкретной области, а топик из юмора — все желающие. Ну и спорить никто никого не обязывает, я вот тоже своё мнение выражаю.
Не вариант. Хабр один из немногих достойных IT-ресурсов, собравший немало айтишников. Вряд ли мне захочется потерять возможность задать вопрос тому или иному из них, подискуссировать в комментах. Речь о том, как бы так изменить затухание на рост.
И сохранить настройки вроде так: //sbin/iptables-save. Помнится вроде так и делал, но что-то не всё выходило. Отпишитесь, если всё получится (и скрипт тоже)).
Тут ещё проблема в том, что эти самые кометообразные костыли не имеют толковых реализаций для неJavaScript-а. По правде, я не знаю приложений, в котором применялись бы comet или web-sockets, кроме браузеров. Ну и смущает сама костыльная природа comet-ов, да и веб-сокеты никак не доделают.
С терминологией дуплексов что-то я напутал. Тут хватит и полудуплекса, то есть нет необходимости в прям одновременной передаче данных, но есть необходимость в способности сервера к асинхронному оповещению клиентов.
Задача такая — на сервере в БД происходит UPDATE таблицы, триггер сообщает об этом серверу, сервер должен сразу оповестить клиента о новых данных (или хотя бы о факте появления новых данных). Можно, конечно, опрашивать по таймеру, но это, говорят, не выход, особенно если много клиентов.
Ага, ага. Спасибо, теперь более-менее прочувствовал структурность. Вот только, насколько я знаю, http не имеет «встроенной» возможности держать соединение, и разного рода HTTP-сервера тут не подойдут. Вы имеете ввиду использовать HTTP в качестве транспорта моего собственного протокола (rest-подобного)? Но при возникновении асинхронного события на сервере он не сможет сразу оповестить клиента, если будет использоваться HTTP (то есть это решается через разного рода web-сокеты и Comet-ы). Я думал всё как-то сразу всё по TCP через сокеты пересылать (по своему протоколу), не задействуя HTTP…
То есть при такой конфигурации полнодуплексное соединение вполне себе будет работать, и только если бы сервер находился за NAT пришлось бы подключать NAT traversal? То есть NAT traversal (STUN и проч.) актуальна лишь для p2p-сетей?
Я правильно понимаю, что для реализации клиент-серверного взаимодействия по первому варианту в общем случае необходимо:
1) Проксировать TCP-соединение через SOCKS-прокси-сервер, если это требуется
2) Использовать к.-л. NAT traversal — технологию для взаимодействия с клиентами, находящимися за NAT-ом.
Есть БД, при обновлении информации в некоторой таблице этой БД необходимо сообщить о ней клиенту (клиентам). Клиент — Windows-desktop приложение или Android-приложение для телефона.
