Я создаю расширение Firefox, которое позволяет использовать Standard ML (SML) в качестве языка программирования на стороне клиента в Firefox.Это работает следующим образом:
- Расширение запускает процесс PolyML (SML-компилятор с интерактивной оболочкой верхнего уровня).
- Затем устанавливается связь сокета между расширениеми процесс PolyML.
- Код SML считывается с веб-страницы и отправляется через сокеты в процесс PolyML для оценки.
- Этот код может затем использовать библиотеку, предоставленную мной, для работыс DOM.
Вот как реализована библиотека DOM:
- Скажите, что кто-то выполняет функцию SML DOM.getElementById
- Этот запрос переадресованчерез сокеты к расширению, где расширение выполняет функцию JavaScript getElementById на странице и отсылает результат обратно процессу PolyML через сокеты.
Мой вопрос в теории, какие ограничения вУсловия работы, которые я должен ожидать здесь, когда дело доходит до сокетной связи?
Я сделал некоторые очень приблизительныеи, похоже, используя этот интерфейс между расширением и PolyML, я могу приблизительно отправить 2500 сообщений в секунду со средним размером 70 байт / сообщение .
Чтобы выразить это в более широком контексте, скажем, я хочу нарисовать некоторые анимации в браузере, используя элемент Canvas.Если я хочу достичь 20 кадров в секунду, это означает, что мне нужно рисовать каждый кадр за 0,05 секунды, что означает, что я могу отправлять только около 125 сообщений на кадр.Эти сообщения соответствуют вызовам функций JavaScript.Например, приведенный ниже код рисует путь и выполняет 9 вызовов функций JavaScript, которые соответствуют 9 сообщениям в сокетной коммуникации.
val _ = Canvas.beginPath context;
val _ = Canvas.setFillStyle context fillColor;
val _ = Canvas.setStrokeStyle context fillColor;
val _ = Canvas.setLineWidth context size;
val _ = Canvas.moveTo context posx posy;
val _ = Canvas.lineTo context posx_new posy_new;
val _ = Canvas.stroke context;
val _ = Canvas.arc context posx_new posy_new (size/2.0) 0.0 6.28 true;
val _ = Canvas.fill context;
JavaScript, очевидно, имеет гораздо лучшийпроизводительность, я думаю, вы могли бы сделать тысячи (сотни) раз больше вызовов функции Canvas / DOM за эти 0,05 секунды, для рисования кадра.
Итак, я думаю, у меня есть вопрос, есть ли у вас какие-либоопыт использования сокетной связи для очень быстрого обмена сообщениями.Я хотел бы знать, кажется ли 2500 маленьких сообщений в секунду (в данном случае, соответствующих 150 килобайтам в секунду) правильным или, возможно, я делаю что-то очень неправильное.
Например, одно подозрение заключается в том, что сокетреализация в Firefox (в частности, использование его через интерфейс JavaScript https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIServerSocket) не очень хорошо для такого быстрого взаимодействия. Например, чтение из сокета осуществляется с помощью механизма цикла событий. То есть я полагаюсь наFirefox .. чтобы уведомить меня о доступности входящих сообщений сокета, и иногда между отправкой сообщения и его получением возникает большая (например, 250 мс) задержка (хотя, похоже, это происходит только тогда, когда firefox занят другими делами, и яменя больше интересуют ... теоретические ... пределы сокетной связи)
Любые идеи, любые мысли, любые недостатки, которые вы видите? Как вы думаете, было бы лучше использовать другие механизмы IPC, например каналы, реализациюмое общение с C ++ XPCOM компонентом, а неиз JavaScript, интерфейс сторонней функции к C (который есть и в JavaScript, и в PolyML)?
(проект расположен по адресу https://assembla.com/wiki/show/polymlext, если кому-то интересно)