to post messages and comments.

? IP udp

Размер датаграммы которую можно отослать без разбивки на несколько TCP пакетов равна MTU — TCP Header — UDP Header (8). Размер TCP header 20-60 байт и зависит он от наличия Options. Что это за опции?

Есть у меня необходимость принимать по UDP пакеты. Выглядит сейчас это - так:
CNU.sourceSocket sock 4096  $= CL.map CNU.msgData
                                    =$= conduitDecode 
                                    =$= CL.map (uncurry EMessage)
                                    $$  CRQ.sinkRollingQueue  q

Принимается пакет, потом десериализуется, а затем суётся в очередь.
Собственно, если данные превышают размер пакета они собираются из нескольких пакетов при этом sender из UDP-шного пакета игнорируется. Тут остаётся актуальным вопрос переупорядочивания UDP-ишных пакетов, т.е. если я засуну в сокет больше 4096 с одной стороны, то на приёмнике могу получить что-то вклинившееся между этими 2-мя пакетами или это просто влияет на размер буфера? 
Сейчас появилась необходимость скомбинировать адресс/порт отправителя  с десериализованным сообщением, учитывая что сообщение может быть разбито на несколько пакетов... Хочется для этого како-то zipConduit использовать, но что-то не очень понимаю как. Собственно помогите с примером.

*brave-new-world Товарищами из коммитетов придумана замечательная опция IPV6_PKTINFO которая, помимо предоставления адреса назначения, скоупа и интерфейса для принимаемых датаграмм (через recvmsg), позволяет указать адрес источника для исходящих датаграмм. Причем каких-либо ограничений RFC не указывает (http://tools.ietf.org/html/rfc3542#section-6.2). Соответственно много реализаций позволяют указывать что угодно (любой валидный unicast адрес). OpenBSD одна из них. Япошки из KAME втихаря поправили это дело слегка 10 лет назад (http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/in6_src.c.diff?r1=1.87;r2=1.88), разрешив использовать только локально сконфигурированные адреса. Однако это не полностью предотвращает возможности инъекции пакетов в локальные сокеты. Solaris "решает" это дело с помощью политик безопасности (fine grained access control), но это означает что программа (например BIND, который пользует IPV6_PKTINFO весьма активно) должна быть соответствующим образом пропатчена или сконфигурирована. Такие дела.

#1209603
ошибка:
cx_Oracle.DatabaseError: ORA-12737: Instant Client Light: unsupported server character set CL8MSWIN1251
заключалась в том что поставил:
oracle-instantclient11.2-basiclite-11.2.0.2.0.i386.rpm 19 метров а нужно было oracle-instantclient11.2-basic-11.2.0.2.0.i386.rpm 54 метра
первый клиент поддерживает не все кодировки =(

Предположим, что есть приложение, где очень важна скорость передачи данных, но столь же важна и приватность. Первое, в идеале, обеспечивает UDP, второе — OpenSSL. Так вот, что лучше — использовать QSSLSocket или пытаться изобретать велосипед и обеспечивать шифрование для UDP?

udp

К #502784 нашел различия в процессах
процессы которых нет в хорошем состоянии
acppage
ashShell
AVRT
ksuser
midimap
msacm32
MSACM32
rarext
sfc
sfc_os
shellext
SYNCENG
syncui
twext
wdmaud
WINMM
xmllite

процессы которых нет в зараженном состоянии
hgcpl
imapi2
netprofm
provsvc
QAgent
SXS
SyncCenter
wkscli
Wlanapi
wlanutil
wwanapi
wwapi
XmlLite