← All posts tagged conduit

Продолжая вопросы из — #2794212 . Собственно расставлением кучи ! мне удалось заставить вылетать эксепшн в нужном потоке. Однако, мне нифига не понравилась такая т.к. мне кажется это совсем не правильным. Т.е. sink по умолчанию ленивый по своим агрументам, и только после того как я сделал его энегричным, что-то заработало.
Собственно встаёт вопрос как принято решать в кондуитах проблемы с тем что санк с эксепшеном может улететь в другой поток?
Кроме того можно, же воспользоваться decodeOrFail . Но насколько я понимаю тогда придётся воспользоваться map Maybe (...) $$ catMaybe $$ sink . Но информация об ошибке пропадает. Чтоб не пропадала придётся писать свой Conduit.

Есть у меня RollingQueue привязанная к UDP сокету. И если в сокет записать херню вылетает эксепшн из Binary десериализатора. Но обрабатывается он совсем не там где я ожидаю. Код тут:
gist.github.com
Подскажите почему так происходит.

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

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

Например у меня есть некий кондуит, который получает по UDP пакеты, преобразует их в нужный мне ADT и пихает в очередь. Выглядит запуск примерно так:

void $ forkIO $ sourceSocket sock 4096 =$= ... =$= sinkRollingQueue

И вот пришло нам битое сообщение из-за него вылетает эксепшн, но я не хочу прибивать весь процесс к чертям из-за такой мелочи. Собственно первое что приходит на ум — это отловить эксепшн с пом onException, вывести в лог сообщение об ошибке и снова запустить кондуит, как-то так:

getMsg =  sourceSocket sock 4096 =$= ... =$= sinkRollingQueue

void $ forkIO $ getMsg `onException` (\e -> print e >> getMsg) 

Собственно вопрос - это обычно так и делается или я что-то упускаю?

Итак есть задача. Проксировать файл по HTTP с проверкой HMAC .
gist.github.com
Есть функция saveAndVerifyBody . Она берёт source и скармливает его 2-м zip-нутым синкам. Один из которых считает HMAC, а 2й записывает по временный файл.
Собственно, хочется сохранять не в файл а отправлять по HTTP дальше. Однако, как-то нормально это не придумывается, т.к. Request принимает как аргумент только Source :( Я пока пришёл только к схеме из функции saveAndVerifyBodyHttp .
Может вы чего подскажете?

Господа, есть вопрос по кондуитам.
Я хочу доработать биндинги для memcached-а. И одна из идей была использовать conduit-ы. И как я сейчас понимаю для этой задачи source/sink не особо то и нужны (т.е. обработка чанками в константной памяти конечно прикольно, однако в моём случае я всегда знаю размер), с другй стороны в yesod-е всё в resourceT и будет освобождение ресурсов в случае ексепшена.
Собственно вопрос, какие есть альтенативы и есть ли они вообще.