adishegde / media_hub Goto Github PK

View Code? Open in Web Editor NEW

25.0 5.0 2.0 2.69 MB

Decentralized file sharing over LAN

Home Page: https://adishegde.github.io/media_hub/

License: MIT License

JavaScript 99.65% Shell 0.20% CSS 0.07% HTML 0.08%

file-sharing mediahub

media_hub's Introduction

Lan based file sharing application.

Introduction

A distributed file sharing application that works out of the box. Simply download the app and start sharing files over LAN. Features that set Media Hub apart:

Video and audio streaming
Fuzzy matching for improved searching
Flexible configuration options to share only required files
Support for meta data like "number of downloads", "file size" and "description"
Multicast and broadcast support
Easy to use core API for building other applications

Installation

Download the latest release for your operating system from the release. Once installed the app will notify all future updates.

To build from source:

Clone the repository.
Run yarn install to install all dependencies.
Run yarn bundle to bundle the Javascript code.
Run yarn package to create an application that will be placed in the dist directory.

Working

Media Hub basically has 2 parts: client and server.

The client is responsible for making search requests and downloading data. Search requests are UDP messages currently made through multicast but the core library supports both broadcast and multicast. Files and their meta data are requested via HTTP.

The server handles all incoming requests. It has a UDP service that handles the incoming search requests and a HTTP server that serves files and meta data.

The core library supports a lot of flexibility with respect to configuration however minimal support has been added to GUI as of v0.1.0.

Contributing

The entire code base is split into 3 parts: core, GUI and CLI.

Core

This is where media hub actually lives. It consists of 2 parts:

daemon: The daemon is the server that handles incoming UDP and HTTP requests. The UDP and HTTP services are managed by instances of the UDPService and HTTPService respectively. The code for the services can be found under src/core/daemon/services.

There is also a file indexer that keeps track of shared files and maintains related meta data. The related files can be found in src/core/daemon/fileIndex. The classes exported from fileIndex are dependent on each other i.e. FileIndex MetaData and SearchHandler are coupled and not completely independent.

Finally the entire daemon logic is abstracted away by the Server class exported from src/core/daemon/server.js. This makes it easy to use the daemon everywhere else.

client: The client provides support for UDP search requests. Making HTTP requests are left to the GUI or CLI apps. The Client class can be found under src/core/client/client.js.

GUI

This contains the code for electron. src/app/main.js is the entry point for electron's main process. src/app/render/index.js is the entry point for electron's renderer process and the React App.

The structure of the render directory is similar to a React-Redux web app.

src/app/utils/client.js exports the client logic by extending upon the Client provided by core. src/app/utils/fileDownloader.js implements a file downloader which is used by client to actually download files.

media_hub's People

Contributors

Stargazers

Watchers

Forkers

zense mirzazulfan

media_hub's Issues

Error handling for HTTP Service

Currently, files are not being served with proper error handling. There might be a lot of possibilities for incorrect headers and requests to result in fatal errors. Thus the HTTP service needs to be cleaned up and proper error handling has to be done.

Calculate broacast IP from subnet

Currently the default broadcast IP is 255.255.255.255. Although this works it's better if the broadcast address is calculated from the subnet of the local IP address. This ensures that router forwards the broadcast packet.

I'm not sure if this can be done efficiently but it is worth looking into.

Server shouldn't respond to search requests from same machine

Currently, the server responds even if the search request is from the same machine. This seems unnecessary and leads to clutter.

The server should not respond if the request is from the same machine. There should be an option to toggle this.

Trying to list file doesn't terminate program

Running a command ./client list <file-url> displays the error URL does not correspond to directory but it does not terminate the program.

This is most probably due to the HTTP request not being terminated.

Resource not found for shared directory

Shared directories are available in the results (due to file indexing) but can't be downloaded due to restrictions placed by HTTP service.

I think it makes more sense to allow download of the entire shared directory. The HTTP service should be modified accordingly.

Fix download increment

Currently the download counter increments for any request at the file URL irrespective of whether a partial range is requested or the entire file. It also increments if the download is cancelled by the client.

This leads to highly incorrect download values in the metadata.

Some file names give 500 error on http service

Downloading some files leads to a 500 response from HTTP service for no apparent reason.

Show downloaded file in directory

Currently, only the path of downloaded files is shown. It would be nice to have a feature to view the parent directory as suggested by @satu0king.

The features I can think about are:

Show file in parent directory
File should be selected when the directory is opened
Try and use electron's native API so that it works across platforms
Handling the case of deleted file or directory

Add config option to ignore files

A config option to match file names when indexing, so that matched files will be ignored, will be helpful for not sharing hidden files and directories. The ignored files will not be indexed nor served.

The config option could be an array of regex strings. If a file name matches with any of the regex expressions it should be ignored.

Large number of shared files crashes app

Sharing a large number of files causes the GUI to lag and eventually might even lead to a crash.

The reason for the GUI lag is due to the load on the main process. Creating a subprocess should reduce the load on the main process and make the GUI work properly.

The following are few more areas which have the possibility of optimization:

DB: Currently everything is being stored in the leveldb instance which might lead to slower data retrieval and write times. Maintaining some kind of index in memory or using a database like nedb which keeps the entire database in memory might improve performance. But the size of the meta data has to be considered.
Using a full blown text search engine like Lucene to improve performance. (Thanks to @adityathiru and @vik-y for suggesting this)

More options in settings page

The core supports a lot of flexibility, however, the GUI does not provide an interface to make use of it. The following options need to be added:

Server Settings

maxResults: Number of items sent per page for each search request.
ignore: List of regular expressions used to match files to ignore.
network: Network name to share among a subset of nodes

Network Settings

udpPort: Port for UDP service
httpPort: Port for HTTP service
mcAddr: Multicast address to which nodes will subscribe
broadcastIp: The broadcast address

Client Settings

useBroadcast: Use broadcast over multicast for search requests
port: Port through which client sends requests
timeout: Time in milliseconds to wait for before closing socket

The settings page can have these options segregated by the subheadings with a small description available on hover. Adding each of the above subheadings can be a separate PR.

Sorting search results

Currently, the search results are not sorted by strength of the match. Each node sorts the files by match score and then sends the page requested but the results aggregated from multiple nodes are not sorted and are instead displayed in the order received.

It would be helpful to maybe reuse fuse.js to sort the results in a particular page.