https://github.com/radrow/tftp-client-coq
TFTP client written and partially proven in Coq and OCaml
https://github.com/radrow/tftp-client-coq
Last synced: over 1 year ago
JSON representation
TFTP client written and partially proven in Coq and OCaml
- Host: GitHub
- URL: https://github.com/radrow/tftp-client-coq
- Owner: radrow
- License: mit
- Created: 2019-06-17T20:13:44.000Z (about 7 years ago)
- Default Branch: master
- Last Pushed: 2021-01-25T10:56:54.000Z (over 5 years ago)
- Last Synced: 2025-01-22T21:28:30.914Z (over 1 year ago)
- Language: Coq
- Size: 25.4 KB
- Stars: 2
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# tftp-client-coq
Simple TFTP client written in Coq (with IO handling done in OCaml) as an assesment for the Computer-Aided Verification course at MIMUW. The program is written as a state machine that reacts on two kinds of events: new packet income and timeout signal from OCaml.
The implementation follows [RFC1350](https://tools.ietf.org/html/rfc1350) standard. The compliance with the specification is ensured by tight typing and constructively proven theorems in intuitionistic logic.
### Example usage
Downloading a file
```
ocamlrun main.byte -h 127.0.0.1 -m w file.txt
```
Uploading a file
```
ocamlrun main.byte -h 127.0.0.1 -m r file.txt
```
### Proven/constrained stuff
- 16 bits bounds checks for datagram naturals
- 8 bits bounds checks for ascii to nat conversions
- Error code bounds and embedding
- Packet sender control (for instance, there is no such thing as "WRQ sent by server")
- Reading/Writing mode packet control (for instance, it is impossible to send WRQ in downloading mode)
- Packet opcode bounds and embedding
- Additional string appending and splitting lemmas
- Reading/Writing mode event control (for instance, it is impossible to receive ACK in Reading mode)
- Error state will persist regardless of events
- Any event that occured after final state leads to an error state
- Receiving block smaller than 512 bytes causes transition to final state
- The communication port (beside initial) doesn't change
- After receiving nth block that is not final client will wait for (n+1)th
- After receiving data block the correct ACK will be sent
- After reaching the end of file the writing state becomes finalized
- After receiving ACK last sent block and there is any data left, the next block will be sent and the state will move on
- After receiving ACK for previous block the previous block will be retransmitted and the state will persist