» Несколько вопросов по сетевому программированию на С++ (азы)

Wc3Exp Молодец, таким и помочь приятно. А то у большинства просьба "помогите" означает исключительно "сделайте вместо меня". На халяву, ессно.

vlary
Это пока ещё из головы не вышло одно из правил предыдущего форума: новый вопрос - новая тема. Неудачное, на мой взгляд, если дело косается программирования. Виноват, извиняюсь и делаю копипаст.

Вопросы:
- как я понял, функциям send(...) и recv(...) вообще "до фонаря" с чем работать, главное указать размер этого чего-то... Это так?
- именно из-за этого "до фонаря" можно переслать структуру, но с приёмом структуры придётся извратиться... Наверное это будет подобно пропусканию куска мяса через мясорубку с последующими попытками обратно собрать кусок мяса из фарша. Что тут можно придумать или уже всё придумано и опробовано?
- обмен структурами с полями фиксированных размеров стабильнее, чем обмен структурами с полями "случайных" размеров... Или всё равно и зависит от реализации?

Wc3Exp
Цитата:

как я понял, функциям send(...) и recv(...) вообще "до фонаря" с чем работать

В общем, да. Они работают с байтами. И это уже забота программиста - перевести экземпляр структуры или класса в последовательность байтов (чем, они физически, по сути дела, и являются), а затем на второй стороне из последовательности байтов собрать данный объект. Фиксированные там поля или нет - в данном случае все равно.

vlary
Если с передачей и приёмом я возможно разберусть, то с разгребанием данных по типам из этой кучи байт я наверное сяду в лужу.

Хотя если буду знать, что первые 8 байт - значение 1го поля стурктуры, следующие 10 байт - значение 2го поля структуры и т.д... то собрать структуру вполне смогу.
Но один серьёзный минус очевиден - придётся пересылать часть пустых полей, что плохо скажется на объёме сетевого траффика.
Но и плюс есть - быстрое разгребание пришедшей кучи байт.

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

Я мыслю в правильном направлении или меня уже нетуда понесло?

Wc3Exp
Цитата:

Я мыслю в правильном направлении или меня уже нетуда понесло?

В принципе - правильно. Смотри в сторону сериализации / десериализации объектов. Чтобы не изобретать велосипед, глянь в сторону библиотеки ACE

Цитата:

Wc3Exp Ну вот сразу же: в обработчике

Цитата:
int client_index = (int)lpParam - 1;
и в главном потоке
Цитата:
NewTreade[client_count] = CreateThread(NULL,0,client_work,(LPVOID)client_count,0,&TreadeId[client_count]);

Ты не правильно параметры передаешь и читаешь.
В сервере должно быть (LPVOID) &client_count, а в клиентском потоке (int)*lpParam
Иначе обработчик вместо индекса сокета нового клиента получит хрен знает что.

Может я слепой, но я не пойму где тут ошибка ?

Добавлено:
Единственное ему client_count++ нужно было делать до создания потока, иначе поток может начать свою работу раньше, чем до client_count++ дойдет.

ClounViruS
Цитата:

Может я слепой, но я не пойму где тут ошибка

Вместо указателя передается значение, это разве не ошибка? Разница между &client_count и client_count понятна? Thread получает параметры по ссылке, а не по значению.

Цитата:

HANDLE WINAPI CreateThread(
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in SIZE_T dwStackSize,
__in LPTHREAD_START_ROUTINE lpStartAddress,
__in_opt LPVOID lpParameter,
__in DWORD dwCreationFlags,
__out_opt LPDWORD lpThreadId
);

Поток получает 4 байта, а что там будет хранить пользователь указатель или число это уже его право.

ClounViruS
Цитата:

а что там будет хранить пользователь указатель или число это уже его право.

Возможно, в данном случае это и прокатит. А вот при передаче массива или структуры - уже нет. Поэтому лучше стараться следовать правилам в мелочах, дабы как-нибудь не обломаться по крупному.