alexcoder04 / rfap-go-server

proof-of-concept file transfer protocol - server side

Archivation Note

As of now, I lost interest on this project and shifted focus to other things. That's why I have to archive rfap-go-server. If you are interested in continuing this project, please email me, so I can explain some details to you or unarchive this repo and add you as contributor.

Maybe I'll work on a new version of rfap with TLS encryption, but that's not sure for now.

---

rfap-go-server

The reference server implementation of the rfap protocol, written in Go. It shares a local folder, which can be then accessed over the network using an rfap client.

See here for protocol specifications and related projects.

Installation

Stable release

Simply download the binary for your OS from the releases page.

Bleeding-edge

Make sure you have git, make and go installed.

git clone https://github.com/alexcoder04/rfap-go-server
cd rfap-go-server

make run       # start testing server
make linux     # compile linux executable
make windows   # compile windows executable
make raspberry # compile linux arm executable
make mac-intel # compile mac intel executable
make install   # compile and install executable to $GOPATH/bin

Please use make to compile the server, because it tells go to inject build information into the executable which is then useful for understanding logs.

Related projects

• https://github.com/alexcoder04/rfap - general protocol specification
• https://github.com/alexcoder04/librfap - Python client library
• https://github.com/BoettcherDasOriginal/rfap-cs-lib - C# client library
• https://github.com/alexcoder04/rfap-pycli - Python CLI client based on librfap
• https://github.com/alexcoder04/rfap-fuse - FUSE filesystem based on librfap

Contributing

We appreciate any kind of contribution! Check out CONTRIBUTING.md for more info.

rfap-go-server's Issues

Refactor read/info/create/write functions

A lot of them do really similar things (error checking), so the code can be organized cleaner

Config file / read configs from the environment

Things like the port, shared folder, log verbosity and location, ... can be read from a config file or the environment

Standartize int variable types

Especially in recv.go we have many different int variable types (int, uint32, uint16), which are converted back and forward. We should standartize them to one same type.

Caching

When rfap-fuse is ready, we will have a first client which does a lot of frequent requests. We could improve performance then, if we cache some data (content of the / folder or contents of large files) in memory.

Documentation

The project is starting to get bigger, so at some point we will need to make a detailed documentation.

Autostart

• Service files for Linux init systems (Systemd, OpenRC)
• How does autostart work on Windows?

Optional JSON logs

JSON logs are available in the logrus logging library which we are using; they are useful for automatic log analysis

Server console

Some kind of way to control the server: restart it, reload the configuration, shut down, ...
Original issue on the main repo:

What should we use for the console?
Stdin is not an option, because we don't have a window with the server running open all the time; moreover the server would print messages while you are typing your command, so it wouldn't really work.
A Unix domain socket would be much better, but it's not supported on Windows (does Windows have something like that?).
Another socket listening on localhost? Seems complicated to me.

The best solution that comes to my mind is to write a simple rfap-go-server-ctl utility which would send messages to the main process.

Refactor conn.go

Most of the cases in the switch statement there do the same thing with different vars. It could be made more clearly arranged.

[Security] RequestDetails

An attacker could crash the server if he requests details (e.g. directory size) on a big directory a lot of times

Splitting large files

Cleaning up source code

The src folder is starting getting a little bit messy and as far as I know, Go code should be located in the root of the repository, so we should structure the code into submodules/subpackets to improve maintainablility

Custom YML (de)serializer

Undefined values in header like 0 or "" have not to be necessary sent, however they are generated by the YML (de)serializer. With use of a helper function, we could filter out these values and reduce size of the header

"Unknown error while readlink"

Return "File not exists" if it is the case

Refactoring connection.go

connection.go became very big and messy, so I will clean it up in the next time.

Implement write/create commands

This work is done in the v0.3 branch.

• file_delete
• file_create
• file_copy
• file_move
• file_write
• directory_delete
• directory_create
• directory_copy
• directory_move

Send / Recv everything at once

Rewrite send.go / recv.go to send and receive whole packet at once

Compile-time variables

Like build time, version, commit hash, ...

Compression

In some future version of rfap, optional compression will be introduced. We will implement it as well as even optionally saving files compressed (only if they are text files of course).

check if header too long

while send and receive

Unit Testing

We should write Unittests and make use of them