На стороне клиента простой html, javascript и websocket. Например:


Очень хотелось бы посмотреть тривиальную реализацию сервера на перл. Желательно через бифы(socket).

Вот что я имею на данный момент, если более подробно:

test.html:



websocket_server.pl :



В браузере выдает: Connection is closed...

А скрипт пишет заголовок:


Помогите докрутиить, а, эту фичу...

Ну идея банально простая... Типичный клиент-сервер..... Тока технически нужно дожать и все...

Сделайте это с Mojolicious и не мучайтесь.

А можно ответтить на вопрос который интересует меня, подчеркиваю?? =)

вы с самим протоколом разобрались?
тогда можете посмотреть тут: http://cpansearch.perl.org/src/MIYAGAWA/Tw...ocket/chat.psgi,
достаточно простая реализация.

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

Вот, что я имею на данный момент, но onopen все равно не срабатывает....

Пробовал по-разному ответный хендшейк формировать, но пока так успеха и не добился... В чем проблема - не вижу!

onopen -- это javascript?

Угу.

В приведеннем мною примере javascript выводит два сообщения. Сначала

WebSocket is supported by your Browser!

потом

Connection is closed...

А хочется чтоб хотя бы раз написал

Message is sent...

порты открыты?

само собой.
От клиента(javascript) я хендшейк-то получаю. А вот ответный хендшейк почему-то не срабатывает

проблема решена, пример реально работающего хендшейка:


Недочеты заключается:
1. в рфс описывается Switching Protocols, а нужно на самом деле Web Socket Protocol Handshake
2. При формировании ответного ключа необходимо дополнять символом '=', и действительно в примерах так оно и укаано, а в описании я об этом ничего не нашел
3. Символы переноса строик и возврата каретки. И здесь тоже изначально трактуется как бы само собой разумеющееся, однако были сомнения, потому что нигде конкретно это не описывается

1. RFC 6455 1.2.  Protocol Overview: The protocol has two parts: a handshake and the data transfer.

2. RFC 6455 1.2.  Protocol Overview: The handshake from the server looks as follows:

        HTTP/1.1 101 Switching Protocols
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
        Sec-WebSocket-Protocol: chat

3. RFC 2616 2.2 Basic Rules: HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body.


"читайте документацию -- она рулез" (ц) чей-то

arto, дословно перевести??

1. Протокол состоит из двух частей: хендшейк и данные
2. Хендшейк от сервера должен выглядить следующим образом(и тут же кстати как раз и неверный хендшейк)

Дальше продолжать??

P.S. Давай не будем устраивать холивар, я в интернете нашел уже несколько статей, подобному моему топику, где разные программисты точно так же описывали с какими трулностями они столкнулись при реализации вебсокеты, жалобы на плохо описанный стандарт есть.

всегда есть куда расти (с)

Это сообщение отредактировал(а) Bulat - 12.7.2013, 14:47

1. ну. в рфц присутствует описание протокола. или описание handshake там отсутствует?

2. а что там именно неверно?

3. по третьему пункту вопросов, как я понимаю, нет?

пс. дамп хендшейка с http://www.websocket.org/echo.html:
Hypertext Transfer Protocol
    HTTP/1.1 101 Web Socket Protocol Handshake\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 101 Web Socket Protocol Handshake\r\n]
            [Message: HTTP/1.1 101 Web Socket Protocol Handshake\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Version: HTTP/1.1
        Status Code: 101
        Response Phrase: Web Socket Protocol Handshake
    Upgrade: WebSocket\r\n
    Connection: Upgrade\r\n
    Sec-WebSocket-Accept: xO65RkfOOMva29LmSc/tSQML7ak=\r\n
    Server: Kaazing Gateway\r\n
    Date: Sat, 13 Jul 2013 08:14:15 GMT\r\n
    Access-Control-Allow-Origin: http://www.websocket.org\r\n
    Access-Control-Allow-Credentials: true\r\n
    Access-Control-Allow-Headers: content-type\r\n
    Access-Control-Allow-Headers: authorization\r\n
    Access-Control-Allow-Headers: x-websocket-extensions\r\n
    Access-Control-Allow-Headers: x-websocket-version\r\n
    Access-Control-Allow-Headers: x-websocket-protocol\r\n
    \r\n
    [HTTP response 1/1]

arto, делать мне больше нечего, как тебя учить.. Если ты не в состоянии увидеть свои ошибки сам.............

учить не надо. просто указать на ошибки.

Давай без обид... Но ты сейчас устроил небольшой флуд, пытаясь гнуть передо мной пальцы и демонстрируя ум, там где его нет.. Я даже не лезу в рфс, я просто процитирую тебя... Обрати внимание на строки

HTTP/1.1 101 Switching Protocols
HTTP/1.1 101 Web Socket Protocol Handshake\r\n

RFC 2616 6.1.1 Status Code and Reason Phrase:

   The Status-Code element is a 3-digit integer result code of the
   attempt to understand and satisfy the request. These codes are fully
   defined in section 10. The Reason-Phrase is intended to give a short
   textual description of the Status-Code. The Status-Code is intended
   for use by automata and the Reason-Phrase is intended for the human
   user. The client is not required to examine or display the Reason-
   Phrase.

ещё есть замечания?

arto, 

HTTP/1.1 101 Switching Protocols
HTTP/1.1 101 Web Socket Protocol Handshake\r\n

Разница в этих двух строках есть или полностью одинаковые??

с точки зрения клиента -- одинаковые.
с тоэки зрения человека -- разные.

советую прочитать соответствующие rfc.

arto, что в лоб, что по лбу   

Я тогда задам вопрос по другому, рфс для кого пишут?? Для "клиентов" или для "людей"??

Чтобы обсуждение не выглядело, как дуэль, тоже задам вопрос

Откуда Вы это правило взяли? У Вас в примере

значение состоит из 27 символов, т.е. оно не соответствует кодировке base64.

И еще вопросик: с каким из заголовков 

не работает?

Это сообщение отредактировал(а) ginnie - 17.7.2013, 17:48

Методом проб и ошибок....

Если мне не веришь, попробуй сам протестируй.



Вот кодировке base64 оно как раз и соответствует.



И с тем и с тем, работающий вариант,

либо

либо

Кто умеет тот делает кто не умеет тот учит других.  Бернард Шоу

т.е. вы не знаете, для кого пишутся rfc?
называется -- приехали, такие сейчас разработчики, хе-хе :)

Добавлено через 3 минуты и 52 секунды
btw, perldoc -m Protocol::WebSocket::Response
...
sub _parse_first_line {
    my ($self, $line) = @_;

    my $status = $self->status;
    unless ($line =~ m{^HTTP/1\.1 $status }) {
        $self->error('Wrong response line');
        return;
    }

    return $self;
}
...

Открываем rfc4648 (The Base16, Base32, and Base64 Data Encodings) и читаем
The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters.  Proceeding from left to right, a
24-bit input group is formed by concatenating 3 8-bit input groups.
These 24 bits are then treated as 4 concatenated 6-bit groups, each
of which is translated into a single character in the base 64
alphabet.
т.е. результат по длине всегда кратен 4 символам, а 27 никак 4 не кратно.

P.S. "Всякая профессия есть заговор против непосвященного." Бернард Шоу

Это сообщение отредактировал(а) ginnie - 18.7.2013, 12:59