Net-WebSocket

 view release on metacpan or  search on metacpan

README.pod  view on Meta::CPAN

=over

=item * The three reserved bits in each frame’s header.
(See L<Net::WebSocket::Frame>.) This is used, e.g., in the
L<permessage-deflate extension|https://tools.ietf.org/html/rfc7692>.

=item * Additional opcodes: 3-7 and 11-15. You’ll need to subclass
L<Net::WebSocket::Frame> for this, and you will likely want to subclass
L<Net::WebSocket::Parser>.
If you’re using the custom classes for streaming, then you can
also subclass L<Net::WebSocket::Streamer>. See each of those modules for
more information on doing this.

B<THIS IS NOT WELL TESTED.> Proceed with caution, and please file bug
reports as needed. (I personally don’t know of any applications that
actually use this.)

=item * Apportion part of the payload data for the extension. This you
can do in your application.

lib/Net/WebSocket.pm  view on Meta::CPAN

management in particular for it to be sensible for a WebSocket library to
impose any one approach. As a result of this, Net::WebSocket can probably
fit your project with minimal overhead. There are some examples
of how you might write complete applications (client or server)
in the distribution’s F<demo/> directory.

Net::WebSocket emphasizes flexibility and lightness rather than the more
monolithic approach in modules like L<Mojolicious>.
Net::WebSocket should support anything
that the WebSocket protocol itself can do, as lightly as possible and without
prejudice as to how you want to do it: extensions, streaming, blocking or
non-blocking I/O, arbitrary HTTP headers, etc. The end result should be a
clean, light implementation that will grow (or shrink!) as your needs
dictate.

=head1 OVERVIEW

Here are the main modules:

=over

lib/Net/WebSocket.pm  view on Meta::CPAN

=over

=item * The three reserved bits in each frame’s header.
(See L<Net::WebSocket::Frame>.) This is used, e.g., in the
L<permessage-deflate extension|https://tools.ietf.org/html/rfc7692>.

=item * Additional opcodes: 3-7 and 11-15. You’ll need to subclass
L<Net::WebSocket::Frame> for this, and you will likely want to subclass
L<Net::WebSocket::Parser>.
If you’re using the custom classes for streaming, then you can
also subclass L<Net::WebSocket::Streamer>. See each of those modules for
more information on doing this.

B<THIS IS NOT WELL TESTED.> Proceed with caution, and please file bug
reports as needed. (I personally don’t know of any applications that
actually use this.)

=item * Apportion part of the payload data for the extension. This you
can do in your application.

lib/Net/WebSocket/Frame.pm  view on Meta::CPAN

    use parent qw( Net::WebSocket::Base::DataFrame );

    use constant get_opcode => 3;

    use constant get_type => 'booya';

Note that L<Net::WebSocket::Parser> still won’t know how to handle such a
custom frame, so if you intend to receive custom frames as part of messages,
you’ll also need to create a custom base class of this class, then also
subclass L<Net::WebSocket::Parser>. You may additionally want to subclass
L<Net::WebSocket::Streamer::Server> (or -C<::Client>) if you do streaming.

B<NOTE: THIS IS LARGELY UNTESTED.> I’m not familiar with any application that
actually requires this feature. The C<permessage-deflate> extension seems to
be the only one that has much widespread web browser support.

=cut

use strict;
use warnings;

lib/Net/WebSocket/Streamer.pm  view on Meta::CPAN

Here’s the gist of it:

    #Use the ::Client or ::Server subclass as needed.
    my $streamer = Net::WebSocket::Streamer::Client->new('binary');

    my $frame = $streamer->create_chunk($buf);

    my $last_frame = $streamer->create_final($buf);

… but a more complete example might be this: streaming a file
of arbitrary size in 64-KiB chunks:

    my $size = -s $rfh;

    while ( read $rfh, my $buf, 65536 ) {
        my $frame;

        if (tell($rfh) == $size) {
            $frame = $streamer->create_final($buf);
        }