mirror of https://github.com/01-edu/public.git
feat(localhost): change to Rust-only project
This commit is contained in:
parent
755249bbb6
commit
60f5aa31c6
|
@ -9,7 +9,11 @@ Here you will learn the basics of the protocol and a good place to start could b
|
|||
|
||||
### Instructions
|
||||
|
||||
- The project can be written in one of these languages [`Rust`, `C++`, `C`].
|
||||
- The project must be written in `Rust`.
|
||||
- You can to use `libc` crate for functions as `epoll` or equivalents and any other necessary system call that Rust do not implement natively.
|
||||
- You may need to use `unsafe` keyword for some operations (don't abuse it).
|
||||
|
||||
> You can't use crates that already implement server features like `tokio` or `nix`.
|
||||
|
||||
#### The Server
|
||||
|
||||
|
@ -25,8 +29,8 @@ Here you will learn the basics of the protocol and a good place to start could b
|
|||
- Your server should be able to receive file uploads made by the client.
|
||||
- Your server should handle cookies and sessions.
|
||||
- You should create default error pages for at least the following error codes [400,403,404,405,413,500].
|
||||
- Your server should call `select` function (or `poll` or equivalent) only once for each client/server communication.
|
||||
- All reads and writes should pass by `select` or equivalent API.
|
||||
- Your server should call `epoll` function (or equivalent) only once for each client/server communication.
|
||||
- All reads and writes should pass by `epoll` or equivalent API.
|
||||
- All I/O operations should be non-blocking.
|
||||
- You should manage chunked and unchunked requests.
|
||||
- You should set the right status for each response.
|
||||
|
@ -59,7 +63,7 @@ In the file you should be able to specify the following:
|
|||
|
||||
> Routes won't need to support regular expressions.
|
||||
|
||||
> There is no need to pass through `poll` when reading the configuration file.
|
||||
> There is no need to pass through `epoll` when reading the configuration file.
|
||||
|
||||
#### Testing your server
|
||||
- Do stress tests (for example with `siege -b [IP]:[PORT]`), it must stay available at all costs (availability should be up to 99.5).
|
||||
|
@ -71,6 +75,4 @@ In the file you should be able to specify the following:
|
|||
|
||||
### Bonus
|
||||
- Handle at least one more `CGI`.
|
||||
- Write the project in two different programming languages.
|
||||
|
||||
> If the two languages are C and C++ the provided solution for C++ should heavily rely on C++ specific features.
|
||||
- Rewrite the project in another programming language (can be `C++` or `C`).
|
||||
|
|
|
@ -9,7 +9,7 @@
|
|||
###### Is the server using only one select (or equivalent) to read the client requests and write answers?
|
||||
###### Why is it important to use only one select and how was it achieved?
|
||||
###### Read the code that goes from the select (or equivalent) to the read and write of a client, is there only one read or write per client per select (or equivalent)?
|
||||
###### Are the return values for I/O functions [read,recv,write,send] checked properly? (checking only -1 or 0 is not enough, both should be checked).
|
||||
###### Are the return values for I/O functions checked properly?
|
||||
###### If an error is returned by the previous functions on a socket, is the client removed?
|
||||
###### Is writing and reading ALWAYS done through a select (or equivalent)?
|
||||
|
||||
|
|
Loading…
Reference in New Issue