Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Спортивный интерес к сокетам 13.12.03 04:21 Число просмотров: 2325
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 13.12.03 05:31 Количество правок: 1
|
Недавно на одном форуме обсуждался вопрос – «Как лучше написать «сервисок»?» Автор - не я. Там я тоже задавал вопрос, на который не получил ответа – «А каким должен быть прикладной протокол, определяющий информационный обмен клиент/серверного приложения, написанного «на сокетах»?».
Только протокол определяет правила обмена данными. Что в протокол заложишь, то в реализации и получишь. И кстати, сокеты здесь не причём. Важный вопрос. Возможно, что автор того потика решал простые задачи – чтение данных из одной или нескольких (но одних и тех же) таблиц удалённой базы. И говорить нечего - любые средства хороши для построения эффективного и надёжного обмена. Оверхеды – минимальны ;)). Возможно, поэтому мне ничего так и не ответили.
Вот схожие ситуации, где я бы тоже не отвечал с учётом их тривиальности:
1) читаем и пишем в таблицы, структура которых известна клиенту «заранее». При этом ещё лучше, если MEMO и BLOB – отсутствуют. Скорее всего, и клиента и сервер здесь проектирует один и тот же человек.
2) пишется протокол под «конкретную» задачу. Есть вполне определённая база. Клиент обращается к серверу не с SQL запросами, а с запросами типа – GET_FOLDERS, GET_DEPARTMENTS. Приблизительно так построено приложение «1C Архив» (если я правильно понял, промониторив сетефой трафик). Совершенно классное и эффективное Российское приложение.
Но мне хотелось выяснить: «Каким должен быть протокол, если предполагается решение немногим более сложных задач? Например, клиентские приложения работают по инет с DBMS так, как если б клиенты использовали DCOM в LAN c Windows-машинами. Задают SQL вопросы и получают достаточно быстро SQL ответы».
Я не занимался и не занимаюсь этой задачей всерьёз. Более того, я б отстаивал существующие промышленные решения, а не суррогат. В корпоративной интранет среде – тем более. Даже для корпоративных сетей, разделённых межсетевыми экранами, я сторонник DCOM, для Win, разумеется (здесь «сложности» с фильтрацией пакетов больше надуманны. Хотя маленько есть, конечно).
Так, что мой вопрос и всё, что ниже – из спортивного интереса и желания узнать, как бы такой «сокетный» протокол проектировали многоопытные .
Невозможно предметно обсуждать «ничего». Поэтому, в свободное от основной работы время я написал протокол, сервер и клиента. Сделал это для «затравки» обсуждения. Из спортивного интереса. Вот код (работающий), реализующий рассматриваемый «сокетный» протокол для «затравки» обсуждения:
_DWORD rc;
_DWORD hQuery;
if ( FAILED(rc = QueryCreate("MY_DB_ALIAS", &hQuery) ))
return rc;
if ( FAILED(rc = QueryOpen(hQuery, "select * from tbl1")) )
{
QueryDelete( hQuery );
return rc;
}
int ival;
LPTSTR sval;
while ((rc = QueryEof( hQuery )) != QUERYEOF_S_EOF)
{
if ( FAILED( rc = QueryIntegerField( hQuery, "id", &ival) )| FAILED( rc = QueryStringField( hQuery, "txt", &sval) ))
break;
_tprintf(_TEXT("id = %d txt = %s\n"), ival, sval);
if ( FAILED(rc = QueryNext( hQuery )) )
break;
}
if ( FAILED( rc ))
OnErr ( rc );
return QueryDelete( hQuery );
В LAN – это работает весьма эффективно. Имеются в виду ощущения пользователя клиентской программы. Для сравнения вот результаты тестирования выполнения того же кода и использованием ODBC и ADO – время выполнения кода, что выше в цикле 100 раз (без _tprintf, разумеется):
1) «На сокетах», с использованием ODBC на сервере ~ 6 сек.
2)Обычное приложение, использующее ODBC и DSN к удалённой базе на том же сервере ~ 5 – 7 сек.
3) Тоже, что и в п.2, но с использованием ADO ~ 1 – 3 сек.
ВНИМАНИЕ ВОПРОС:
Каким должен быть протокол, если это не LAN, а инет?
Ред. 1 раз.
|
- [C++] Спортивный интерес к сокетам - void 13.12.03 04:21 [2325]
|
|
|
подробно о проекте
Анализ криптографических сетевых...
