| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как грамотно работать с сокетами
Piter © (2005-08-19 15:16:00)Пишу плагин для программы. С WinApi приходится работать через внутренний API программы, но фактически это реализается блокирующих сокетов.
Вот думаю - как лучше организовать прием/передачу данных.
Допустим, я сделал поток - он принимает данные, в какой-то момент поток "завис" на Receive (данных нету).
А если в это время надо что-то отправить? Делать другой поток?
То есть, прием данных в одном потоке, передача в другом? Или как это грамотно реализовать?
Digitman (2005-08-19 16:44:00) [21]
> пинг меряется
разберись уже в конце-концов в терминологии и протоколах ..
пинг (ping - пакетный Интернет-щуп) есть ничто иное как инф.обмен по протоколу icmp
Digitman (2005-08-19 16:37:00) [22]
> Piter © (19.08.05 16:13) [6]
тогда, скорей всего, ты ограничент только возможностями этого АПИ.
думаю, что бессмысленно пытаться из двух разных потоков по одному и тому же блок.соединению одновременно принимать и передавать данные - удаленный хост у тебя наверняка работает в режиме "запрос-ответ" и поддерживает ли он колбэки - это еще бабушка надвое сказала
> кто говорит о постоянной бесполезной пинговке?
тыговоришь)
или я тебя не понял ..
> где пинг по 10мс бывает
по 10мс это что - период или длительность ?
зачем, спрашивается, нужен icmp, когда сам tcp всегда известит меня об разрыве/отказе коннекта с удал.хостом в момент когда я пытаюсь что-то передать или принять ?
Eraser (2005-08-19 16:29:00) [23]Piter © (19.08.05 16:13) [6]
Поэтому там конечно не эхо-запрос/ответ, но пинг меряется по ходу дела постоянно.
Пинг меряется именно при передачи данных. Под пингом в этом случае подразумевается время отклика на запрос.
Piter (2005-08-19 16:19:00) [24]А, вот еще что забыл.
Так 500мс - это нормально? Или поменьше/побольше надо сделать?
Piter (2005-08-19 16:13:00) [25]Digitman © (19.08.05 15:52) [5]
какое отношение всякие прокси-серверы имеют к трансп.уровню ?
да блин. Объясняю еще раз. Я ведь не WinApi использую, я использую API той программы, для которой пишу плагин.
Я не делаю вызовов WinApi, я делаю вызовы API программы. Я и говорю, что на самом деле там фактически реализованы блокирующие сокеты.
Но не на прямую.
Например, я работаю как бы напрямую с удаленным хостом, но программа, если в ней есть настройки, может пустить это через какой-нибудь Socks прокси. Я даже и не буду знать, что работаю через прокси, а мне это и не надо.
Digitman © (19.08.05 15:52) [5]
в мусор такие игры !
зачем, спрашивается, без конца пинговать удаленный хост
кто говорит о постоянной бесполезной пинговке?
Ты когда-нибудь играл в сетевые 3D-Action? Там ведь действие происходит непрерывно, непрерывная передача данных в обе стороны.
Поэтому там конечно не эхо-запрос/ответ, но пинг меряется по ходу дела постоянно.
Digitman (2005-08-19 15:52:00) [26]
> Piter © (19.08.05 15:40) [3]
> чем select не подходит?
>
> не понял - а причем здесь он?
вот там как раз и можно задать таймаут ожидания того или иного свершившегося трансп.события
> учитываются всякие общие настройки, вроде прокси сервера
> и всего такого
какое отношение всякие прокси-серверы имеют к трансп.уровню ?
это уже прикладной уровень, на этом уровне фактический режим работы гнезда совершенно безразличен
> Ожидать чтения, после возврата управления отправлять из
> очереди, потом опять ожидать чтения. А как с производительностью
> при этом?
Гнездовые Инди-объекты по сути так и работают.
И на производительность пока вроде никто не жаловался.
Хотя , думаю, такой подход полностью оправдан лишь при разработке кроссплатформенного кода трансп.уровня.
Если же речь идет лишь о Win32, я не вижу причин не воспользоваться удобствами и преимуществами неблок.режима с использованием того или иного механизма асинхр.нотификаций о трансп.событиях гнезда
> как те же онлайновые игры, где пинг по 10мс бывает
в мусор такие игры !
зачем, спрашивается, без конца пинговать удаленный хост, если его вдруг возникший отказ можно обнаружить в любой момент обычной операцией send или recv ?
Eraser (2005-08-19 15:41:00) [27]Piter © (19.08.05 15:16)
В дополнении, как транспортное средство можно использовать уже готовые решения, как mailslots, но тут по обстоятельствам смотреть надо.
Piter (2005-08-19 15:40:00) [28]Rouse_ © (19.08.05 15:25) [1]
А чем select не подходит?
не понял - а причем здесь он? Он вроде как тоже заблокирует поток на время ожидания подключения, например, после Connect. Как он поможет... я немного не понял :(
Digitman © (19.08.05 15:25) [2]
реализуй на неблокирующих
API программы это не предусматривает. А использовать этот API желательно, так как учитываются всякие общие настройки, вроде прокси сервера и всего такого.
Digitman © (19.08.05 15:25) [2]
используй таймаут ожидания чтения - по истечению таймаута recv() вернет управление, и ты сможешь в том же трансп.трэде использовать это же гнездо для передачи
да, я об этом думал... Ожидать чтения, после возврата управления отправлять из очереди, потом опять ожидать чтения. А как с производительностью при этом?
Я вот думаю таймаут где-то в 500мс поставить - нормально будет?
И интересно - а как те же онлайновые игры, где пинг по 10мс бывает.. Они на неблокирующих сокетах или у них время "опроса" катастрофически малое?
Rouse_ (2005-08-19 15:25:00) [29]Обязательно блокирующие? А чем select не подходит?
Digitman (2005-08-19 15:25:00) [30]
> фактически это реализается блокирующих сокетов
реализуй на неблокирующих - проблема сама собой отпадет
если же нужен именно блок.режим, то используй таймаут ожидания чтения - по истечению таймаута recv() вернет управление, и ты сможешь в том же трансп.трэде использовать это же гнездо для передачи
в принципе, насколько мне известно, гнездо как Winsock-объект является thread-safe-объектом, т.е. хэндл одного и того же гнезда после установления соединения можно использовать в разных трансп.тредах (один передает, другой принимает) без крит.секций или иной синхронизации ... но рисковать я бы не стал - лучше и надежней либо работа в неблок.режиме либо в блок.режиме по таймауту
| |
Страницы: 