gwbasic / bounce Goto Github PK

main.rs needs tests:

• Full server and full client setups
• Error conditions with bad environment variables and bad arguments

If the client is connected to the server, it doesn't detect that the server is shut down.

Something needs to happen, (maybe via the socket,) that tells the client to shut down too.

Instead of println!, use a dedicated logger.

The logger should have warn, info, debug, error, and fatal levels

When using async code in rust, there are a lot of idle threads.

See if the async engine can be configured to be single-threaded; or follow a thread-per-core model.

When running bounce without a key, try to run a dummy web server.

This is for running under Heroku, as a way of saying "I'm running" when no key is set up

There should be a mode to generate public and private keys.

For example, "bounce keys" should generate both public and private keys, ideally encoded using base64. Example output:

Bounce
Generating keys
Public key: gesTREYngfdeEREWT675437
Private key: jytr7654HGSHT245hfdgh

The server doesn't detect that client shut down. When the client shuts down, it sits listening to an idle socket instead of waiting for a new connection

The cipher object can not live between calls to await.

See if there is a way to not have to continually recreate it. Perhaps it can be placed inside an Arc?

In the current implementation, the nonce is continually reused for each encrypted packet.

Instead, find a PRNG (psuedo random number generator) that always generates the same output from the same seed. Determine the seed at authentication, and use this to generate new nonces for each packet.

Note that some PRNGs that accept seeds may change on a platform-specific basis; or via software updates.

Add support for Heroku

A common Rust pattern is matching on an error, and then returning the error.

See if there is some kind of macro that will return the error. (Similar to letting exceptions bubble out without handling them explicitly.)

The bounce client should be authenticated using a public/private key mechanism.

• The server should know the client's public key. (Via a command-line argument or environment variable.)
• The client should know its private key. (Via a command-line argument or environment variable.)
• Upon connection, the server should encrypt a success message (and something random)

auth.rs uses "select" to implement timeouts.

Instead, use https://docs.rs/async-std/1.7.0/async_std/io/fn.timeout.html to implement timeouts

Ongoing communication on the socket should be encrypted. The specific mechanism to do this is to be determined.

Consider: https://github.com/neosmart/cryptostream