Не большой вопрос по протоколу TCP и клиент-серверному приложению

Всем доброе время суток!

Начнем, пожалуй, с не большого предисловия…

Так уж вышло, что весь мой опыт в программировании построен на PHP и JavaScript, и обычном сайтостроении. А все познания в C# и Python закончились на ознакомлении с материалами для начинающих, был дикий интерес к этим языкам, но ввиду большой занятости пришлось отложить это до лучших времён. По сему за возможную глупость и непонимание чего-либо не пинайте сильно.

Теперь ближе к делу…

Появилась необходимость сделать простенький клиент к части сайта, то бишь на сайте есть страница с несколькими кнопками (конечно же, для зарегистрированных пользователей), так вот эту часть и надо вынести в клиент, чтобы работать можно было, не открывая браузер. Сразу оговорюсь, что использовать элемент WebBrowser не вариант.
Что касается клиента, то при запуске программы, происходит соединение с сервером, проверка наличия обновлений (чего на самом деле ещё долго не будет), затем авторизация и уже сам запуск клиента. Клиент – это не большое окно с несколькими кнопками, клик по каждой открывает своё окно. Большую часть времени клиент просто находится в режиме запуска и если для пользователя есть новое сообщение или какая-то новая информация, он должен получить её. Вот собственно и весь клиент.

И наконец-то вопрос…

И занялся, я значит изучением написания клиент-серверных приложений и протокола TCP (ранее работать приходилось только с HTTP). И во всех материалах, статьях и примерах, что мне попадались… Твердили, что необходимо указывать максимальное количество одновременных соединений, их конечно можно не указать, но тогда велики шансы, что сервер может, не справится (а это уже плохо). Тогда получается (в моём случае), надо указать это самое количество, но чтобы (если вдруг окажется, что клиентов много) не приходилось лишним ожидать, после каждого запроса надо разрывать соединение. А чтобы клиент вовремя получал уведомления, просто вешаем таймер, который будет отправлять через n-ое количество секунд (минут), запрос на сервер. И вот когда я дошёл до подобных умозаключений, я задался вопросом «в чём же тогда разница между TCP и HTTP протоколами?!», ведь, по сути, у меня получается то же самое, что и обычная web-страница с ajax-запросами. И достаточно просто закинуть на хост парочку PHP-скриптов, что будут отвечать на запросы и всё. Но если это так, то, наверное, я, что-то не понял.

Собственно вопрос в том, где мои мысли пошли не в том направлении и куда их всё же стоит направить? Какой всё же подход будет более правильным в данном конкретном случае? И как всё же пишут клиент-сервер с постоянным соединением и без ограничения одновременных подключений?

P.S.: Я наверное слегка слукавил, когда в названии тему написал «не большой вопрос» и спасибо всем кто осилил сей вопрос и дочитал до конца.

-----
Судя по ходу мыслей, вас постоянно преследуют глупости.

пишу с телефона потому текста мало.

tcp как и udp транспортный уровень. и он ничем не похож на http. его задача совсем другая.
а по сабжу: юзайте вебсокеты. если в вебе лучше разбираетесь - то и делайте в нем

Это протоколы разного уровня.
HTTP работает поверх TCP и не имеет постоянного соединеия.


шо значит вынести? Что именно вынести? Куcок HTML ?


если речь идет о части сайта то других вариантов кроме браузера и нет.
Разве что curl.

потрудитесь навести порядок в своих мыслях и сформулиролвать вопрос технически более четко и без бла-бла-бла

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

http://ru[dot]wikipedia[dot]org/wiki/TCP

http://ru[dot]wikipedia[dot]org/wiki/HTTP



Думаю далее не стоит копипастить. Вы уже сами можете взглянуть на модель OSI

1. В мыслях и идеях каша.

Почему? - Потому что начинать изучения сайтостроения как раз и нужно было не с сайтостроения а стека протоколов TCP/IP, и HTTP и 90% вопросов решились бы сами собой.

2. В контексте озвученных задач не понятно почему вы не можете использовать в качестве клиента приложение js исполняемое в браузере. Запросы к серверу, обновление баз, хранение баз данных на таком клиенте, — сегодня все это вполне возможно и практикуется (web storage и т.п.).

3. Что касается технологий разработки клиента, если все же указанное выше решение окажется для вас не подходящим, то к выбору нужно подходить с позиции целесообразности. Если вы разрабатываете мультиплатформенное клиентское приложение (ещё один + для варианта из пункта 2) для ПК и других платформ на никсовых операционных системах, то использование C# тут будет нецелесообразным в том случае, если задействование всей мощи NET вам не требуется. Тем не менее, вести на данном языке разработку под никсоандроиды и даже IOS вполне возможно, равно как и разрабатывать мульти-платформенные приложения, разумеется, с использованием специальных надстроек (http://xamarin[dot]com/monoforandroid ). Но это не ваш случай. Питон, либо, ещё проще, — php + Devil Studio (или иная прокладка) могут стать более простой с позиции трудозатрат платформой для вашего клиента, насколько о нем можно судить из столь скупого запроса функционала.

(Отредактировано автором: 11 Сентября, 2013 - 10:12:38)

Если бы необходимость была именно в этом, то я бы и воспользовался бы WebBrowser и никаких проблем, но я видимо не совсем корректно написал Мне надо было повторить визуально в клиенте, часть что есть на сайте. Почему именно так? Просто, учитывая некоторые нюансы о которых я не написал, я решил, что так будет проще.

esterio, спасибо, но я догадался прочитать описание, до того как создать эту тему. Да и вопрос был не в этом, а в том что на деле у меня получалось, что надо закрывать соединение, что в свою очередь уже никак не получалось "постоянным". Хотя в целом я уже нашёл подходящий пример и вопрос как бы решён.

Zuldek, огромное спасибо за ваш ответ.

-----
Судя по ходу мыслей, вас постоянно преследуют глупости.

Предполагаемое решение поставленной задачи, заключающейся в осуществлении формировании элементов пользовательского интерфейса целевого приложения, являющегося эквивалентным или обеспечивающим сопоставление требуемых объектов с визуальных позиций, при условии отсутствия применения общих определений объектов интерфейса, с точки модельных составляющих в первичном повышенном уровне базового элементного трактования, не является самым оптимальным решением, поскольку требует формирование общих модельных составляющих для дифференцированных активных действенных составляющих, определяемых во вторичном пониженном уровне базовой элементной трактовки, в соответствии с чем предполагаемым оптимальным решением может являеться фомирования приложения, соединение модельной и физической составляющей которого является идеологически эквивалентнрым решению, построенному на базе применение объекта WebBrowser, наследующего из активной среды исполнения .net framework, однако осуществление перевода HTML-элементов во вторичный пониженный уровень базвого элементного трактования осуществляется не директивным непосредственным методом, а производится на основании предшествующего анализа входящих HTML-информационных полей, представленных в первичном пониженном уровне базового элементного трактования, и выполнения ассоциированных функциональных составлюящих, включающих сопоставление физических образов для предполагаемой визуальной модели, которые в частности в условиях использования технологии HTA, могут быть непосредственно преоразованы в ассоциированные объекты верхнего уровня с точки хрения модельной составляющей, в то время как функционального целевого приложения, в области делегируемых привелений, является эквивалентной настольном классическому программному обеспечению

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/