Тем что оно овер HTTP и работает за сквидом.

А у Вас тег тупняк отклеился. Двусторонняя связь же

костыли и подпорки

Так и по TCP двусторонняя связь есть уже лет 40 (или когда там его изобрели)

что, нету ppp over http?

Где? Ссылкопруфы в тред

Это называется обратной совместимостью.

что, нету ppp over http?

Разве он не ниже в модели OSI чем WS?

Совсем другие уровни абстракции, у вас действительно какой-то тег отклеился.
WebSocket базируется на HTTP, который в свою очередь работает на TCP протоколе...
Первый протокол для полнодуплексной связи браузера и сервера, второе протокол транспортный.

Простой пример использования: http://ru.lichess.org/
Браузер вместо того чтобы долбить сервер, спрашивая не сделал ли ход другой игрок, мирно открывает сокет и слушает.

Надо добавить до появления WS браузеры в сокеты не могли никаким другим образом.

вот тебе простейший пример

http://www.cyberforum.ru/c-linux/thread52594.html

Есть даже ppp over jabber

Т.е. реализуется L3 поверх более высокого уровня.

А установить обычное TCP-соединение (транспортный уровень) и писать/слушать в него не судьба?

А вообще, это очень похоже на велосипедный и ни с чем не совместимый ppp over http

Другой уровень.

Ну... Откройте мне TCP-соединение средствами браузерного JS.
Хаха, что Вы курили?

Ты спрашивал где в TCP двусторонняя связь? Я тебе привел

Либо же чуть модифицированный вариант:

#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdlib.h>

int main()
{
    int err=-1;
    int server_sockfd, client_sockfd;
    int server_len, client_len;
    struct sockaddr_in server_address;
    struct sockaddr_in client_address;

    server_sockfd = socket(AF_INET, SOCK_STREAM, 0);

    server_address.sin_family = AF_INET;
    server_address.sin_addr.s_addr = htonl(INADDR_ANY);
    server_address.sin_port = htons(9734);
    server_len = sizeof(server_address);
    err=(bind(server_sockfd, (struct sockaddr *) &server_address, server_len));

    if(err!=0)
        printf("bind error!\n");
    else
        printf("bind is ok\n");
    err=-1;

    err=(listen(server_sockfd, 5));
    if(err!=0)
        printf("listen error!\n");
    else
        printf("listen is ok\n");
    printf("server waiting\n");

    client_len = sizeof(client_address);
    client_sockfd = accept(server_sockfd, (struct sockaddr *) &client_address, &client_len);

    while(1)
    {
        char ch;
        if (read(client_sockfd, &ch, 1) != 0)
        {
                ch++;
                write(client_sockfd, &ch, 1);
        }
        else
                break;
    }
    close(client_sockfd);
    printf("exiting\n");
}

В этом случае вообще соединение только 1 раз создается, а потом в него пишется и читается много-много раз

Ну так может лучше сделать в браузере ppp over http и пользоваться им, вместо того, чтобы городить свой велосипед?

И это не говоря о том, что в обычных приложениях это уже лет 40 есть, и зачем делать то же самое в браузере - непонятно

И это не говоря о том, что в обычных приложениях это уже лет 40 есть, и зачем делать то же самое в браузере - непонятно

А мне непонятно, почему там этого до сих пор не было.

Впиливание чего-то инородного в существующий API — это велосипедостроение как раз.
Еще раз WS высокоуровневый протокол. Кодера клиентской части байтотрах интересовать не должен, а вы его в JS впиливать предлагаете каким-то образом. Зачем непонятно, разве что по причине что Вы ретроград.

Да не в TCP же. Уровень другой.

Слишком рисковано разрешать браузеру пулять пакеты налево-направо и открывать сокеты, управляемые клиентским кодом.
Открывается гигантская перспектива для разнообразных инъекций, кросс-сайтовых атак и воровства пользовательских сессий.

Не кури дурь-травы на ночь.

WebSocket - готовый протокол, работающий поверх обычного TCP.

В чем преимущество: готовый стандарт. Или ты предлагаешь каждому, кто захочет юзать WebSocket, пилить свой протокол и клиентские реализации на JS?! Я уже молчу об серверных, и какой бы хаос был и туева хуча несовместимых протоколов.

ppp обеспечивает стандартный ip-канал. В нем ты можешь использовать вообще что угодно. вебсокеты, судя по описанию, являются тем же самым, но с велосипедным протоколом.

Так и по TCP двусторонняя связь есть уже лет 40 (или когда там его изобрели)

Где? Ссылкопруфы в тред

твои слова?

WebSocket ж не over HTTP. Там только handshake позаимствован из HTTP, дальше ничего общего с HTTP там не вижу.

А давно сквид научился проксировать websocket? Раньше для этого юзал HAProxy и nginx с какими-то патчами, добавляющими проксирование TCP-соединений. Благо, теперь у него есть нативная поддержка.

А разве вебсокеты на js написаны? Нет же. Ну и pptp-клиента в браузер интегрировать так же можно

туева хуча несовместимых протоколов.

я предлагаю использовать хорошо проверенный pptp

Вебсокеты позволяют ооочень просто обмениваться браузеру текстовыми и бинарными данными с сервером. В случае использования IP-канала опять же надо стряпать свой протокол.

Какой свой протокол? У тебя есть 65535 tcp портов в pptp-канале. Можешь на каждую переменную по порту выделить.

А порядок обмена данными (а что собственно передавать) в любом случае согласовывать надо.

Давай предположим, что твоё желание осуществилось. У нас есть полноценный IP-канал. Ни больше, ни меньше. Мы умеем по нему слать UDP и TCP пакеты.

Как отправить примерно один мегабайт данных из браузера серверу или наоборот?

Какой код должен быть на клиентской и серверной стороне?

Со стороны пишущего:

В начале работы обратиться к порту.

.....................

Записать мегабайт.

..................

В конце работы закрыть порт.

Со стороны принимающего:

В начале работы открывам порт и дожидаемся, когда к нему соединятся

...................

Принимаем мегабайт

...................

закрываем порт

фейспалм тред

Допустим, я хочу передать из сервера JSON в UTF-8 неизвестного браузеру размера.

Что мне нужно будет? Писать код, который, как минимум, будет следить за:

• Все ли данные получены. Обычно это 1-8 байт перед самим сообщением, где указана длина сообщения в байтах. Так 1 или 8? Или 4?
• Валидация UTF-8.
• Договорённость с клиентом и сервером об кодах ошибок и реакции на них.
• В любом нормальном свежерождённом протоколе должен быть handshake и версионность самого протокола. Иначе — грабли в будущем при попытке изменить или расширить.

Заметь, это всё надо сделать ещё до начала реализации обмена сообщениями между сервером и клиентом. Это, так сказать, низкоуровнёвые потроха.

И так в каждом проекте.

А как же взаимодействие между различными клиентами и серверами?

С текущими WebSocket сервер может выложить публичный API в виде JSON запросов и ответов, которые реализуются в JS очень легко. А если клиентам надо будет ещё тянуть реализацию протокола?

к стати, а если надо интенсивно обмениваться данными — тоже соединение закрывать/открывать? если нет — то см. ответ выше об проверке, все ли данные получены.

ы?))

Вот что мне не нравится в WebSocket — так это masking key. Какая-то защита от дурака, которая разве что мешает читать дамп пакетов в plain-text. Казалось бы, хочешь защиты — юзай wss (WebSocket TLS/SSL).

А так — лишь дополнительный оверхед (впрочем, всем похер, так как тормозом является обработка данных с помощью JS в браузере, а не простейшие бинарные операции, к тому же выполнены в нативном коде).

Проблема: нежданно для клиента передать срочное сообщение. Текущие реализации на ajax этого не позволяют, клиент сначала запрашивает есть ли новые данные и если есть получает их в исходном запросе.

Проблема: объемы сервисных данных превышают объемы полезной информации, что приводит к удорожанию решения.

Детали и картинки: http://www.websocket.org/quantum.html

Да просто делать людям нечего и они впихивают в браузер всё, что только в голову взбредёт. Раньше как было? Есть протокол, если клиент для работы с ним. А сейчас всё в брозёр, всё в брозёр. В итоге получаем жирнофоксы и прочие толстохромы, которые собираются дольше чем ядро+DE операционной системы и ресурсы жрут как космические корабли.

Зато юзверям удобно. Легче покупать каждые пару лет новый комп, чтобы он смог запустить браузер, вместо того, чтобы освоить две-три простых программы.

Ага, просто прекрасно работает за squid http://img94.imageshack.us/img94/9396/websocket.png

А сейчас всё в брозёр, всё в брозёр

при этом на мобильных платформах всё наоборот

толковое обьяснение =) надо будет почитать как это использовать. я так понял это альтернатива AJAX?

и да, с этого момента что-то изменилось?
http://www.opennet.ru/opennews/art.shtml?num=28944
Ъ:
Разработчики Firefox и Opera приняли решение отключить поддержку протокола WebSockets, входящего в число спецификаций группы HTML5.

Через год после этой новости WebSocket стандартизируют http://tools.ietf.org/html/rfc6455 а реализации в текущих на тот момент браузерах будут признаны безопасными. Такие дела. Как бы готово для продакшена.
Другое дело окружение пока не готово. Для популярных скриптовых язычков нужно подключать дополнительные модули, что на shared-хостинге попросту невозможно, а поддержка со стороны веб-серверов реализуется теми же модулями-костылями. Вон nginx научился пробрасывать WS только месяц назад в последней версии...
Для AJAX-а же никаких телодвижений не требуется вообще.

tcp сам следит за передачей

Что же до версий, то какая разница, через WS ты будешь гнать устаревшую версию или через tcp?

ОПА!

А как это я в этом сраче еще не поучаствовал?

Вообще, вебсокеты еще сильно сырые: они охрененно избыточные. По-человечески, нужно просто разрешить JS открывать любой сокет. И выкинуть в анус это чертово "шифрование"!

А давно сквид научился проксировать websocket?

Кстати, надо будет проверить.

Просто не пойму, с чего бы сквид не проксировал вебсокеты: это же обычные сокеты!

Почитал, нет оно не поверх http

Давно. С разморозкой.

Firefox 4

У тебя реально криокамера протекла!