Synapse TTCPBlockSocket "молчит"

[hinst]

Делаю обмен данными по сети между приложениями.
Сейчас у меня делается примерно так:

Код: Выделить всё

  ...
  Net := TTCPBlockSocket.Create;
  Net.SetLinger(True, 10000);
  Net.Connect('localhost', '50058');
  ...
  WriteLN(stream.Size);
  stream.Position := 0;
  Net.SendStream(stream);
  ...


Но это даже не важно
Важно то, что подключиться он не может. И не должен, так как на localhost:50058 никто не слушает
Но тем не менее никаких сообщений об ошибке я не получаю
Метод Connect - процедура, ничего не возвращает. Как узнать, подключился он или нет? Я думал, должно быть исключение, но его нет
Метод SendStream - процедура, ничего не возвращает. Тоже не ясно, как узнать, отправил он данные или нет.
И в общем у меня эта программа работает, выключается, как будто подключение установлено и данные отправлены, но так не должно быть. Ну я думаю понятно.......

Что за фигня?

[debi12345]

Тоже не ясно, как узнать, отправил он данные или нет.

Synapse так устроен - в процесс трансфера данных (чтобы посмотреть например сколько уже передано) можно встрять только через коллбэки если таковые предоставлены. Иначе - только анализировать коды возврата примерно в таком духе :

Код: Выделить всё

function connect_check(const host: msestring; const port: msestring; const timeoutms: cardinal = 0): boolean;
var
Socket: TTCPBlockSocket;
begin
result:= false;
Socket := TTCPBlockSocket.Create;
try
  Socket.Connect(host, port);
  result:= Socket.LastError = 0;
finally
Socket.Free;
end;
end;


и
циклиться по таймаутам и количеству попыток до нужного кода возврата.

И зачем Вы используете низкоуровневые сетевые процедры ? Почему не высокоуровневые HTTP & Co коннекты ?

[hinst]

потому что у меня не HTTP
потому что я не скачиваю страницы и не делаю http-запросы
задача такая в общем
надо передавать данные, постоянно и быстро

Добавлено спустя 1 минуту 36 секунд:
я уже так и понял, что надо по LastError проверять, ну ок
получается что функция Connect по идее должна быть блокирующая, то есть пока не подключится (либо не отглючится), управление вызывающему не возвращается

[debi12345]

получается что функция Connect по идее должна быть блокирующая, то есть пока не подключится (либо не отглючится), управление вызывающему не возвращается

Не всегда удобно. Например если сервер молчит и т.п., то придется выжидать полный таймаут только для того, чтобы увидеть фигу - что например совершено недопустимо для сканнинга сети и т.п. Так что араратовцы думаю здесь правы

Добавлено спустя 13 минут 15 секунд:
CONNECT по сути шлет SYN-пакет и тупо ждет ответный ACK-пакет (с таймаутом сетевого драйвера). Синапсовские настраиваемые таймауты выжидаются только при обмене блоками данными после коннекта.

[hinst]

что-то я тупился-тупился с этой библиотекой......
Вроде бы всё кое-как сделал, одна только фигня:
когда данные не передаются, то подключение обрывается и главное никакого сообщения об ошибке не приходит, он делает вид, что всё отсылает

Добавлено спустя 1 минуту 2 секунды:
debi12345 случаем на сталкивался?

Добавлено спустя 12 секунд:
или не сталкивалась

[debi12345]

когда данные не передаются, то подключение обрывается и главное никакого сообщения об ошибке не приходит, он делает вид, что всё отсылает

Кто рвет соединение ? Драйвер сетевой карты по таймауту неактивности ?
Или серверная сторона - для этого рекомендую посмотреть траффик TCPDUMP-ом (WireShark-ом,..)- шлются ли FIN/ACK-пакеты (сигнал и квитанция) перед самым разрывом.

главное никакого сообщения об ошибке не приходит, он делает вид, что всё отсылает

А как Sуnapse может узнать об ошибке ? Только по факту недоставки данных, о которой он знает - то есть ожидает в очереди отправки или приема. Либо тупо поллить (пинговать или ACK-ть) соединение (держать очереди непустыми) - что не есть "good".

[hinst]

В общчем я кажется врубился, что там за фигня у меня была:

Код: Выделить всё

    socket.RecvStream(stream, 20000);


вот когда это вызываешь, и данные не приходят 20 секунд, то этот вызов возвращает управление и (!) устанавливается код ошибки Connection timed out:

Код: Выделить всё

if socket.LastError <> 0 then
begin
  WriteLN('Error: ' + socket.LastErrorDesc);
  socket.Free;
end;


Ну и у меня было сделано чтобы входящий сокет закрывался как только происходит "ошибка". А это оказывается не ошибка, просто данные не приходили в течение этого времени. А я-то сидел тупился. Надо видимо игнорировать WSAETIMEDOUT для входящих подключений

[debi12345]

А я-то сидел тупился. Надо видимо игнорировать WSAETIMEDOUT для входящих подключений

Таймаут (и код ошибки по его истечению) после установки коннекта отсчитывается только для операций передачи/приема данных. Если ничего не шлешь и не ожидаешь и в это время произошел разрыв соединения, то узнать о нем можно только по ошибке трансфера следующей порции данных.

Добавлено спустя 3 минуты 34 секунды:

socket.RecvStream(stream, 20000);

Скорее надо изменить алгоритм У ВАс этот код использует сервер ? Можно посмотреть для примера, как в Synpse сделаны цикла ожидания траффика FTP и HTTP-серверов.

Добавлено спустя 4 минуты 23 секунды:
HTTP-ридер :

Код: Выделить всё

function THTTPSend.ReadUnknown: Boolean;
var
  s: ansistring;
begin
  Result := false;
  repeat
    s := FSock.RecvPacket(FTimeout);
    if FSock.LastError = 0 then
      WriteStrToStream(FDocument, s);
  until FSock.LastError <> 0;
  if FSock.LastError = WSAECONNRESET then
  begin
    Result := true;
    FSock.ResetLastError;
  end;
end;


Добавлено спустя 2 часа 21 минуту 39 секунд:
Кстати

socket.RecvStream(stream, 20000);

выглядит опасным. Таймаут здесь для одиночных пакетов или всего потока (который может быть большим) ?