xkor, угу, приблизительно так и делаю. за исключением того что всетаки WSPRecv, и крипт/декрипт будут в основном приложение.
и кровь тут ЕСТЬ.
а именно. в
delphi Код:
function WSPRecv(s: TSocket; lpBuffers: LPWSABUF; dwBufferCount: DWORD;
var lpNumberOfBytesRecvd, lpFlags: DWORD;
lpOverlapped: LPWSAOVERLAPPED;
lpCompletionRoutine: LPWSAOVERLAPPED_COMPLETION_ROUTINE;
lpThreadId: LPWSATHREADID;
var lpErrno: Integer): Integer; stdcall;
а точнее в
delphi Код:
lpBuffers: LPWSABUF;
LPWSABUF = ^_WSABUF;
_WSABUF = record
len: u_long; // the length of the buffer
buf: PAnsiChar; // the pointer to the buffer
end;
понятно что при вызове этой функции ей передается указатель на уже созданный в памяти _WSABUF, изменить указатель на указатель новой структуры созданной вручную не получится. приложение его просто проигнорит продолжая читать данные со старого поинтера.
поэтому приходится работать с уже существующей в памяти структурой
как то вот так
delphi Код:
CopyMemory(lpBuffers.buf,
буффер_обработаный_приложением(возможно со своими данными впереди),
длинна_нового_буфера);
узкое место тут одно:
длинна_нового_буфера должна быть <= lpBuffers.len иначе нехватит места в памяти чтобы записать данные в буфер который получит клиент.
благо при обмене с ГЕЙМСЕРВЕРОМ(не с ЛС), КЛИЕНТ (не проверял на волкере и прочих) резервирует буфер длинной 16к. далеко не всегда используя его полностью.
отсюда вывод - буфер который требуется отправить НА клиент с помощью контролирующего приложения и буфер который клиент получает от сервера по длине суммарно не должны превышать 16к.
зы.
с отправкой от клиента такой проблемы нет, ибо я могу отменить отправку и отправить данные вызвав send от имени клиента. так что если разбить модуль на части
1. перехват отправки, изменение данных на такие же подлинне либо меньше - готово.
2. перехват отправки, изменение данных на данные по длине превышающие изначально отправляемые -готово
3. самопроизвольная отправка данных от имени клиента на сервер - готово
4. перехват принимаемых клиентом данных и изменение их на данные с такой же длинной либо меньше - готово
5. перехват принимаемых клиентом данных и изменение их на данные с длинной больше - возможны проблеммы.
6. самопроизвольная отправка данных на клиент - невозможно. реализация через предыдущий пункт.
то готовность самого лсп модуля около 5/6, остается проблемный 5й пункт...
буду дальше в свободное от работы время мучать WSPRecv.
зы2.
LOL, не смеши. смотри выше скрин, они встроили кодировку пакетов при отправке, ТУТ эта криптовка не обсуждается.
да и я пока не интегрировал эту вещь в пакетхак. НИКАКОЙ разборки протокола нет.