Я понимаю, что прошло два года. Но вдруг.
Столкнулся я с интересной засадой (а так как Вы упоминаете что у вас куча абонентов через микротик ходили в тот момент — я думаю вы должны были с этим столкнуться и как-то порешать).
Засада такая:
Если два абонента сидящие на одном устройстве решили обмениваться данными между собой, то получается, что трафик ходит только через одну очередь. Что в simple queue, что в queue tree. И решить эту проблему можно только используя одновременно оба типа очередей (например гонять исходящий траффик через simple queue, а входящий через queue tree), что, как по мне, как-то дико.
Как вы подобную засаду решали?
Нет. Если цель «заражение ради заражения, а если носитель сдохнет — то и черт с ним, а то и сами ему целенаправленно поможем» — это вирус. Если цель «спрятаться и стараться ничего не ломать (а то и лечить — есть и такие компьютерные вирусы, которые лечат от других вирусов и мешают заражать), ну и по мимо этого делать что-то своё» — это бактерия.
А переполнение буфера — это методика заражения. Этим и бактии и вирусы могут пользоваться. Ну пока, по крайней мере, «переполнение буфера» само распространяться не научилось.
По поводу «неконсистентный» я даже спорить не буду, благо ровно тем-же самым словом не так давно этот язык и описывал.
Правда по другой причине (работа с каналами, возврат нескольких значений из функции), но ощущение такое-же.
for node := range tree.PreOrder() {
fmt.Println(node)
}
Так сделать можно. Если нет необходимости прервать итерирование в процессе — верните канал и поднимите горутину, которая будет в этот канал по одному объекту класть.
Впрочем для таких случаев я бы скорее написал что нибудь а-ля tree.foreach.
defer и замыкание — очень не бесплатные, на самом деле. groups.google.com/forum/#!topic/golang-ru/MlRvTOxWvig
Т.е. использовать такое внутри частых и длинных циклов — не очень хорошая идея.
Встроили-бы уже в язык нормальный интерпретатор и не мучались. И ключевое слово «interpret» для отделения того, что должно интепретироваться от того, что должно компилироваться.
>Условно что сейчас IP 1.2.3.4 соответствует I2P адресу abcd и дальше обмен трафиком между ними идет уже напрямую
Причем делается достаточно просто.
1. При настройке роутера указываешь блок серых адресов, на которые будут мапиться i2p адреса. Один из этих адресов — адрес роутера.
2. Роутер поднимает интерфейс с адресом из этого блока.
3. Роуер поднимает DNS сервер, который резолвит *.i2p в адреса из серого блока. С каким нибудь мелким ttl.
После этого начинает работать весь софт, и серверный и клиентский, который вообше ни сном ни духом о всяких прокси и соксах.
От него есть исходники.
Столкнулся я с интересной засадой (а так как Вы упоминаете что у вас куча абонентов через микротик ходили в тот момент — я думаю вы должны были с этим столкнуться и как-то порешать).
Засада такая:
Если два абонента сидящие на одном устройстве решили обмениваться данными между собой, то получается, что трафик ходит только через одну очередь. Что в simple queue, что в queue tree. И решить эту проблему можно только используя одновременно оба типа очередей (например гонять исходящий траффик через simple queue, а входящий через queue tree), что, как по мне, как-то дико.
Как вы подобную засаду решали?
А переполнение буфера — это методика заражения. Этим и бактии и вирусы могут пользоваться. Ну пока, по крайней мере, «переполнение буфера» само распространяться не научилось.
Правда по другой причине (работа с каналами, возврат нескольких значений из функции), но ощущение такое-же.
fmt.Println(node)
}
Так сделать можно. Если нет необходимости прервать итерирование в процессе — верните канал и поднимите горутину, которая будет в этот канал по одному объекту класть.
Впрочем для таких случаев я бы скорее написал что нибудь а-ля tree.foreach.
groups.google.com/forum/#!topic/golang-ru/MlRvTOxWvig
Т.е. использовать такое внутри частых и длинных циклов — не очень хорошая идея.
Erlang
Причем делается достаточно просто.
1. При настройке роутера указываешь блок серых адресов, на которые будут мапиться i2p адреса. Один из этих адресов — адрес роутера.
2. Роутер поднимает интерфейс с адресом из этого блока.
3. Роуер поднимает DNS сервер, который резолвит *.i2p в адреса из серого блока. С каким нибудь мелким ttl.
После этого начинает работать весь софт, и серверный и клиентский, который вообше ни сном ни духом о всяких прокси и соксах.
Осталось сесть и написать. :)