saltyrtc / saltyrtc-client-js Goto Github PK

View Code? Open in Web Editor NEW

29.0 29.0 6.0 2.71 MB

SaltyRTC JavaScript implementation.

License: MIT License

TypeScript 96.41% JavaScript 2.72% HTML 0.87%

client javascript saltyrtc signaling

saltyrtc-client-js's People

Contributors

Stargazers

Watchers

Forkers

oguzhane maniacs-satm chribben alerdenisov ark-us jpsaman

saltyrtc-client-js's Issues

Add tests

We should be able to test the code without any existing webclient.

@lgrahl, do you know what the easiest way would be? Can we test client/server on a single machine?

Integration with Travis would also be welcome.

Remove AngularJS specific code

Right now all classes are exposed as AngularJS services. That's not relevant here and can be removed.

This also means that the logging system needs to be replaced.

Signaling: Performance improvements

Some messages in the handshake can be sent in parallel, instead of waiting for the other peer.

Validate sender byte

The sender byte should always be validated.

Once the handshake is done, messages with a different sender byte should be dropped.

@lgrahl it's correct that they should be silently dropped, right?

Dependency Handling

Should we compile-in a copy of the msgpack and nacl libraries?

Pro:

A single file distribution, simple installation
Depending on how the packaging is done, saltyrtc will always use a known version of the required libraries, avoiding incompatibilities with other versions of the same library

Con:

Larger file size
Separate dependencies required to use
Conflicts could be possible if the application using saltyrtc also brings along its own msgpack and/or nacl library

@lgrahl what do you think?

Alternatively we could also provide two distributions, a fat and a light one.

Readme needs update

I guess the readme is simply outdated? It lacks setting a task. Or is there a default task?

Complete documentation

Publish prose docs
Publish API docs
Update README

Properly handle protocol errors

https://github.com/saltyrtc/saltyrtc-meta/blob/master/Protocol.md#client-to-client-messages

Compared to client-to-server messages, protocol errors for client-to-client message MUST be handled differently. In case that any check fails, the procedure below MUST be followed unless otherwise stated:

If the other client is not authenticated yet, an initiator SHALL drop the corresponding responder by sending a 'drop-responder' message with the responder's address in the id field to the server and a close code of 3001 (Protocol Error) in the reason field. A responder SHALL close the connection to the server with a close code of 3001.
If the other client is authenticated and the error cause is not a 'send-error' message from the server, the client SHALL send a 'close' message to the other client containing the close code 3001 (Protocol Error). In any case, both clients SHALL terminate the connection to the server (normal close code).

Fix double encryption

The same issue as saltyrtc/saltyrtc-client-java#42 probably applies here too.

It might be possible to create a cleaner solution thanks to the single threaded nature of JS.

Implement Event Handling

As discussed in saltyrtc/saltyrtc-meta#34

interface Event {
    type: string,
    data: any,
}

type EventHandler = (ev: Event) => boolean | void;

// Register an event handler
on(event: string | string[], handler: EventHandler): void;

// Run an event handler only once
once(event: string | string[], handler: EventHandler): void;

// Cancel an event handler
off(event: string | string[], handler?: EventHandler): void;

Base events are connected, connection-error, connection-closed and data
The data event can be specialized, e.g. data:offer will only match events where offer matches the dataType
If a handler returns false, the corresponding listener will be removed
An event can be registered or deregistered for multiple events by passing in an array
If the handler is omitted in the off(event) call, all handlers will be removed
If an event handler is already registered, it is not registered a second time

Examples:

// Classic event handler
salty.on('connected', (event) => console.log('SaltyRTC is connected'));

// One-time event handler
salty.once('data', (event) => console.log('The first message arrived.'));

// Data event handler that can remove itself
salty.on('data', (event) => {
  if (event.data.dataType === 'panic') {
    console.error('everybody panic');
    return false;
  }
});

// Specialized event handler(s)
salty.on(['data:offer', 'data:answer'], (event) => {
  console.log('A', event.type, 'event is being handled');
  let dataMessage = event.data;
  console.info('Message', dataMessage.dataType, 'with value', dataMessage.data);
});

// Deregistration
function acceptPranswer(event) {
  console.log('pranswer arrived');
}
salty.on('data:pranswer', acceptPranswer);
salty.once('data:answer', (event) => {
  console.log('final answer arrived');
  // Don't accept pranswers anymore
  salty.off('data:pranswer', acceptPranswer);
});

Unify sender/receiver/source/destination flags

The terminology used is not consistent.

connection-closed event

Right now it's possible that the connection-closed event is thrown twice when closing the connection directly (once in resetConnection and once in onClose).

Maybe there's a way to detect whether the closing was done by us or by the server?