yigal_s' Journal
[Most Recent Entries]
[Calendar View]
[Friends View]
Wednesday, November 14th, 2012
| Time |
Event |
| 4:03a |
заточка мозгов Оказывается, Dual-N-Back тренажер доступен в виде freeware на http://brainworkshop.sourceforge.net/Там можно и более сложные конфигурации задавать, скажем, не Dual, а Triple и далее. Маленький секрет - чтобы начать в это играть, стоит сначала попробовать отдельно нажимать на клавиши только лишь визуального, а потом только лишь аудио-канала. Потом брать комбинированный вариант, а потом, уже овладев уровнем, переходить на следующий и там снова начинать тренировать раздельно видео и аудио. Во всяком случае, так построена тренировочная программа в Lumosity на младших уровнях. Примерно на восьмом уровне у пользователя начинает открываться канал в ноосферу, о которой писал академик Вернадский, а к пятнадцатому к нему прилетают ангелы в белых халатах. А вот, кстати, сами авторы метода тренировки бесстыдно обещают вам золотые горы: Ранее по теме: http://yigal-s.livejournal.com/802775.html | | 7:38p |
об сокет (повторно)
мои страдания месячной давности вокруг полузакрытых сокетов под виндами давно уже разрешились,
но вдруг неожиданно обнаружился об этом детальный репорт Микрософта. Буквально под носом, в официальной документации к функции shutdown (как же я раньше-то не заглянул?):
"If the how parameter is SD_RECEIVE, subsequent calls to the recv function on the socket will be disallowed. This has no effect on the lower protocol layers. For TCP sockets, if there is still data queued on the socket waiting to be received, or data arrives subsequently, the connection is reset, since the data cannot be delivered to the user. For UDP sockets, incoming datagrams are accepted and queued. In no case will an ICMP error packet be generated."
Иными словами, если вы делаете shutdown приёмной части сокета, когда на нем еще есть данные, или если они приходят позже, после того как вы зашатдаунили приёмную часть, то имплементация ресетит коннекшен, собственно говоря, ударяя уже по передающей части, которая вообще ни в чем не виновата.
Возможно, тут вообще изначально вина на разработчиках TCP и/или sockets API, так как каждая сторона может закрыть свою посыльную часть (послав FIN), но вот если она закрывает приёмную часть - вроде бы мейнстримного способа другой стороне об этом узнать - нету. Ну разве что вот так - завязав статус приёмного и передающего канала, как сделал Микрософт. Если такой мейнстримный способ всё же есть - поправьте меня, пожалуйста. |
|