April 30, 2016 at 16:49UDP / TCP File System, Trivial Remote File System
Today is a day off, so I’ll write briefly about trifles to which, as a rule, hands do not reach.
There is one more thing that is not present in modern Unix and which I want to have in a unix box of a phantom. It is simple as a moo, and why no one did it is incomprehensible:
True, I want to use a different file name syntax, URL style - tcp: // host: port, but this is already the details. Naturally, along with TCP, UDP is requested, and there are generally no problems there.
For TCP, there is an obvious problem - do we need listen or connect, but it can be solved by specifying a specific suffix in the “file” name.
There is nothing more to say on this subject that we will move on to the next without stopping.
In one of the test environments, the Phantom worked on a diskless machine and wanted to organize remote paging over the network. For this, I made a minimal network FS.
References:
The protocol is reminiscent of tftp with oak, but it allows asynchrony - the request does not have to wait for a response synchronously, instead the client sends requests without waiting and shame, can receive responses randomly and re-requests the timeout that was not received.
The exchange is in sectors. In fact, the Phantom itself uses the protocol exactly as a remote disk.
The file is accessed by session identifier and file identifier. This allows you to omit dereferencing and work with files by fixed numbers if necessary - again, this is done in this implementation, the Phantom always asks for file number zero, the server itself knows where to look for it. But there is a request to "get a number by name."
The session identifier is used as a marker of the fact that the server was restarted and forgot the file numbers. In this situation, the session identifier will show a mismatch and the client will receive an error that needs to be processed by re-asking the file number for the given name again. However, I did not write this part of the protocol, since I myself do not need it yet.
The protocol is so lightweight in terms of implementation that even a server can be pushed into a weak microcontroller. And the client is even more so.
The protocol runs on top of UDP. Use on health, if required. With all its simplicity, due to asynchrony and out of order resend, the protocol is quite effective. Only if you need an orderly execution of requests is it necessary to ensure the outside. TRFS itself will happily work out in the order that the responses arrive over the network.
TCP FS
There is one more thing that is not present in modern Unix and which I want to have in a unix box of a phantom. It is simple as a moo, and why no one did it is incomprehensible:
#cat /tcp/host/port > local_file
True, I want to use a different file name syntax, URL style - tcp: // host: port, but this is already the details. Naturally, along with TCP, UDP is requested, and there are generally no problems there.
Spoiler heading
In general, the Phantom's unix subsystem “eats” both traditional Unix names, /usr/include/stdio.h , and URLs, tcp: //ya.ru: 80 .
For TCP, there is an obvious problem - do we need listen or connect, but it can be solved by specifying a specific suffix in the “file” name.
There is nothing more to say on this subject that we will move on to the next without stopping.
TRFS is a trivial remote file system.
In one of the test environments, the Phantom worked on a diskless machine and wanted to organize remote paging over the network. For this, I made a minimal network FS.
References:
The protocol is reminiscent of tftp with oak, but it allows asynchrony - the request does not have to wait for a response synchronously, instead the client sends requests without waiting and shame, can receive responses randomly and re-requests the timeout that was not received.
The exchange is in sectors. In fact, the Phantom itself uses the protocol exactly as a remote disk.
The file is accessed by session identifier and file identifier. This allows you to omit dereferencing and work with files by fixed numbers if necessary - again, this is done in this implementation, the Phantom always asks for file number zero, the server itself knows where to look for it. But there is a request to "get a number by name."
The session identifier is used as a marker of the fact that the server was restarted and forgot the file numbers. In this situation, the session identifier will show a mismatch and the client will receive an error that needs to be processed by re-asking the file number for the given name again. However, I did not write this part of the protocol, since I myself do not need it yet.
The protocol is so lightweight in terms of implementation that even a server can be pushed into a weak microcontroller. And the client is even more so.
The protocol runs on top of UDP. Use on health, if required. With all its simplicity, due to asynchrony and out of order resend, the protocol is quite effective. Only if you need an orderly execution of requests is it necessary to ensure the outside. TRFS itself will happily work out in the order that the responses arrive over the network.