Аппаратный кеширующий прокси сервер в разрыв LAN кабеля доступа интернет.
Подскажите как лучше сделать?
Предполагаю сделать на базе двух PIC18f67j60.
Один чип для входа, другой чип для выхода.
Один чип HTTP клиент, другой чип HTTP сервер.
Меж чипами SPI флеш память на несколько ГБ.
Меж чипами i2c канал связи для передачи команд и данных управления и статуса работы.

Как думаете, это верная парадигма?

По типу этого устройства:

У меня, как у админа со стажем - ваша парадигма вызывает неподдельную такую, широоокую улибку )))))
И как у разработчика(с не таким большим стажем) - тоже.
Таким девайсом разве что только дайлапный инет раздавать и то с тормозами

А в чем проблема? Там 10 мбит соединение и 25 мил. операций в секунду. Этого недостаточно для наших менее мегабита интернетов?

Проблема в подходе к проектированию.

Нарисуйте Ваше устройство в виде квадратов "входной интерфейс", "память", "выходной интерфейс".
Потом ознакомьтесь с протоколами TCP/IP, HTTP, работой прокси и прочим, прочим, не забывая добавлять дополнительные подробности в схему.
Детально продумайте, что каждый квадрат будет делать.

А только потом можно думать, как именно реализовывать в железе всю эту идею. Боюсь, там не останется ни http-сервера, ни пиков, ни spi памяти на несколько ГБ.

Сейчас я занят интернет радиоприемниками с битрейтом звука до 256 кбит/сек на базе PIC контроллеров 8 бит и 25 мГц тактовой частоты. Проблем указанной скоростью передачи данных протокола по типу HTTP нет + TCP/IP. Думаю, справится бы и с мегабитом.

макет кухонного интернет ражиоприемника
http://electronix.ru/forum/index.php?showtopic=82530

В стопицот раз разумнее взять либо x86 совместимую платы типа mini ITX(а вообще и меньше были), и поставить туда линух. Прикрутить эту вашу крутилку больше-меньше и дело в шляпе ))
А лучше конечно на базе какой-нибудь ARM дэмоборды.... там, правда, всё чуть сложнее будет...
Про эти пики точно забудьте.
А ещё, нынче инет надо расчитывать на ~15 - 20мегабит ))

Ну и т.д. и т.п.
Почитайте системные требования на Squid и по форумам пошарьте... это хотя-бы даст представление о требованиях к оперативке ))
Дело же не только в скорости, а и в кол-ве соединений...

Простейшую ручку-крутилку скорости инета сделать можно на достаточно низком уровне и может быть даже на пиках...
Предлагаю не подниматься выше ethernet кадров и тупо дропать их по секретному алгоритму )
А вот и секретный алгоритм:http://ru.wikipedia.org/wiki/Random_early_detection ))))

а разбор HTTP, кеширование и шейпинг - это не для пиков, уж точно.

Проблема в том, что кеширующий прокси требует как минимум разбор HTTP протокола и написать это без чудовищного количества багов за разумное время у Вас вряд ли получится.

да такая "парадигма" не широкую улыбку, а истерику вызывает

ну и зачем здесь х86 и ITX? что за писюканство? берем любой роутер (из свободно поддающихся пилению - искать по *-WRT) на мипсе-арме баксов за 40-50, к нему на любом самом дешевом пике-тини по кому прикручиваем крутилку-смотрелку и настраиваем шейпер. все проблемы (ядро, софт, коммутатор, lan-wan) уже решены за нас. бонусом достается вафля и пристойный корпус. и вагон и маленькая тележка всяких разных приятных сервисов типа логов, веб-интерфейса и прочее-прочее. как самый (наверное, из того, с чем приходилось работать) дешевый - DIR-300 за $25. ну еще можно посмотреть на совсем китайцев типа тенды и прочих.
итого по затратам выходит $25+$10=$35 и неделя времени (и это с запасом на вылизывание). мало что собственное сможет конкурировать (варианты вагонных масштабов в задаче не озвучены).

Все понятно. Вопрос решен

ну так кешровать то он не будет)) Я исходил из задачи кеширование+шейпинг.

Ну если посмотреть на интернет приемник автора то можно понять и какой "прокси" сервер он хочет.
Это скорее всего нечто заточенное под одну страницу, на один конеект и один тип содержания
Такое сделать на PIC-е гораздо легче чем на самом навороченом линуксе.

Ну... это уже телепатия пошла))

Кстати, картинка в первом посте понравилась!