Подскажите, пожалуйста, как можно организовать проверку на timeout по приему данных, если использовать Socket.BeginReceive?
После BeginReceive запускаю таймер, который, если не был выполнен асинхронный делегат приема данных, срабатывает, но вот как по событию таймера отменить BeginReceive не знаю. Буду благодарен за советы.

Здравствуйте, Marek, Вы писали:

M>Подскажите, пожалуйста, как можно организовать проверку на timeout по приему данных, если использовать Socket.BeginReceive?
M>После BeginReceive запускаю таймер, который, если не был выполнен асинхронный делегат приема данных, срабатывает, но вот как по событию таймера отменить BeginReceive не знаю. Буду благодарен за советы.

Наверное придется просто закрывать сокет. При этом выполнится callback-метод, и если там вы вызываете EndReceive(), то наверное будет исключение ObjectDisposedException (влом проверять), так что предусмотрите это.

Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте, Marek, Вы писали:

M>>Подскажите, пожалуйста, как можно организовать проверку на timeout по приему данных, если использовать Socket.BeginReceive?
M>>После BeginReceive запускаю таймер, который, если не был выполнен асинхронный делегат приема данных, срабатывает, но вот как по событию таймера отменить BeginReceive не знаю. Буду благодарен за советы.

MC>Наверное придется просто закрывать сокет. При этом выполнится callback-метод, и если там вы вызываете EndReceive(), то наверное будет исключение ObjectDisposedException (влом проверять), так что предусмотрите это.

А как в общем случаи грамотные люди делают проверку на timeout?)

Здравствуйте, Marek, Вы писали:

M>А как в общем случаи грамотные люди делают проверку на timeout?)

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

Если отмена не поддерживается, клиенту остаётся не много: или просто перестать ждать или взвести флаг о том, что результат операции более не актуален и осоществлять какие-то действия уже в End-методе.

Здравствуйте, MozgC, Вы писали:

M>>Подскажите, пожалуйста, как можно организовать проверку на timeout по приему данных, если использовать Socket.BeginReceive?
M>>После BeginReceive запускаю таймер, который, если не был выполнен асинхронный делегат приема данных, срабатывает, но вот как по событию таймера отменить BeginReceive не знаю. Буду благодарен за советы.

MC>Наверное придется просто закрывать сокет.

А что при этом произойдёт на сервере? Перестанет ли он обрабатывать запрос?

Здравствуйте, _FRED_, Вы писали:

_FR>А что при этом произойдёт на сервере? Перестанет ли он обрабатывать запрос?
Если речь о чтении/записи в сокет на другой стороне соединения, то свалится с ошибкой, скорее всего, WSAECONNRESET (10054).

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, Marek, Вы писали:

M>>А как в общем случаи грамотные люди делают проверку на timeout?)

_FR>Вопрос в том, поддерживает ли ваша асинхронная операция отмену. Если не поддерживает, то отменить её в общем случае нельзя. Так же некоторые асинхронные операции сами имеют таймаут, и пользователю достаточно его выставить.

_FR>Если отмена не поддерживается, клиенту остаётся не много: или просто перестать ждать или взвести флаг о том, что результат операции более не актуален и осоществлять какие-то действия уже в End-методе.

Спасибо за идею — думаю при срабатывании таймера выставлять флаг неактуальности и заново запускать запрос на данные.

Здравствуйте, Marek, Вы писали:

M>Спасибо за идею — думаю при срабатывании таймера выставлять флаг неактуальности и заново запускать запрос на данные.
Socket.BeginReceive Method:

To cancel a pending BeginReceive, call the Close method.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Marek, Вы писали:

M>>Спасибо за идею — думаю при срабатывании таймера выставлять флаг неактуальности и заново запускать запрос на данные.
HL>Socket.BeginReceive Method:
HL>

HL>To cancel a pending BeginReceive, call the Close method.

HL>

Я читал это, но получается, что вызывая Close мы закрываем соединение, что мне не подходит.

Здравствуйте, HowardLovekraft, Вы писали:

_FR>>А что при этом произойдёт на сервере? Перестанет ли он обрабатывать запрос?
HL>Если речь о чтении/записи в сокет на другой стороне соединения, то свалится с ошибкой, скорее всего, WSAECONNRESET (10054).

С обращением к самому сокету всё понятно. Вопрос в выполняющейся логике: она при закрытии сокета так и будет выполняться (например, форматировать диск), пока не попробует что-то со своей стороны отправить.