wxSocket вопросы по использованию

[m1t0z]

Здравствуйте. Решил попробовать сокеты в wx. Но по ходу дела, возникло несколько вопросов:

1. Можно ли узнать сколько байтов информации, находится во внутреннем буффере приема. Т.е. чтобы, например, перед вызовом wxSocketBase::Read, узнать точно сколько можно прочитать и тем самым не залипнуть в функции.

2. Прошу пояснить назначение метода wxSocketBase::WaitForWrite. Если после его вызова возрващается true, могу ли я вызвать wxSocketBase::Write, не боясь залипнуть( при условии, что сокет установлен как блокирующийся ). Или же за таймаут функций Read, Write и им подобным отвечает лишь функция wxSocketBase::SetTimeout().

3. Если не привязываться к механизму event_ов, можно ли как нибудь узнать, что соединение потерянно( аналог wxSOCKET_LOST )

[tan]

Привет.

Здравствуйте. Решил попробовать сокеты в wx. Но по ходу дела, возникло несколько вопросов:

вообще то я с wx сокетами вообще дела не имел Но, в свое время, довольно плотно с обычными сокетами работал (под разными платформами).

1. Можно ли узнать сколько байтов информации, находится во внутреннем буффере приема. Т.е. чтобы, например, перед вызовом wxSocketBase::Read, узнать точно сколько можно прочитать и тем самым не залипнуть в функции.

В обычных сокетах можно (ioctlsocket(sock, FIONREAD, &l) - возвращает в l число байтов для чтения), но вроде в wx сокетах доступа к системному хандлеру сокета нет. Но можно и без этого обойтись. Читай в неблокирующем режиме. Прочтеться сколько есть (не более чем запрошено), потом используй LastError() и LastCount() для анализа. Ничего не залипнет

2. Прошу пояснить назначение метода wxSocketBase::WaitForWrite. Если после его вызова возрващается true, могу ли я вызвать wxSocketBase::Write, не боясь залипнуть( при условии, что сокет установлен как блокирующийся ).

Вызвать, конечно, можно Однако гарантии, что ВСЕ требуемые данные будут переданы без тормозов нет. Вдруг ты захочешь за один вызов передать N-е число мегабайт через сокет работющий по модему Но для практически реальных ситуаций (и нормальном прикладном протоколе) все должно работать без блокировки.

3. Если не привязываться к механизму event_ов, можно ли как нибудь узнать, что соединение потерянно( аналог wxSOCKET_LOST )

wxSocketBase::IsConnected() не подходит?
А чем event-ы не нравяться? С ними проще будет работать. Единственный альтернативный работоспособный вариант (для общего случая более менее сложной системы) это использование потоков (threads). Не думаю, что это более простой путь.

[m1t0z]

Спасибо, tan. На днях сяду за написание собственной обертки wxSocketClient. Думаю, что новые вопросы по использованию сокетов будут

[m1t0z]

1. Метод wxSocketBase::Destroy. Правильно ли я понял, что после вызова данного метода сокет лишь помечается как удаленный, но реальное удаление произойдет лишь тогда, когда обработаются все socket events, относящиеся к данному сокету и находящиеся на момент вызова wxSocketBase::Destroy в "очереди" обработки. Вопрос возник в связи с тем, что после вызова Destoy, указатель на сокет приравниваю NULL. А в обработчки событий от сокета, используют этот сокет( т.е. обращаюсь по указателю ). Правильно ли я опасаюсь обращения по NULL?

[tan]

1. Метод wxSocketBase::Destroy. Правильно ли я понял, что после вызова данного метода сокет лишь помечается как удаленный, но реальное удаление произойдет лишь тогда, когда обработаются все socket events, относящиеся к данному сокету и находящиеся на момент вызова wxSocketBase::Destroy в "очереди" обработки.

Ну, в общем, все правильно.

Вопрос возник в связи с тем, что после вызова Destoy, указатель на сокет приравниваю NULL. А в обработчки событий от сокета, используют этот сокет( т.е. обращаюсь по указателю ). Правильно ли я опасаюсь обращения по NULL?

Если явно используешь в обработчике переменную, содержащую указатель (которой уже присвоен NULL), то, конечно могут быть проблемы. Очевидный выход - используй в обработчике указатель на сокет, который возвращает метод wxSocketEvent::GetSocket(), он будет корректен.