UDP / TCP File System, Trivial Remote File System
Today is a day off, so I will write briefly about the little things that, as a rule, do not reach the hands.
There is one more thing that does not exist in modern Unix and which I want to have in the unix box phantom. It is as simple as mooing, and why no one did it is incomprehensible:
')
True, I want to use a different syntax for the file name, the URL style is tcp: // host: port, but these are details. Naturally, along with TCP, UDP is requested, and there are no problems at all.
For TCP there is an obvious problem - do we need a listen or connect, but it can be solved by specifying a certain suffix in the name of the “file”.
There is so much more to say on this subject that we will proceed without stopping to the next one.
In one of the test environments Phantom worked on a machine without a disk and wanted to organize remote paging over the network. For this, I made a minimal network FS.
References:
The protocol is reminiscent of tftp oak, but asynchronous - the request does not have to wait for a response synchronously, instead, the client sends requests without waiting and shame, can receive answers separately and re-request the time not received.
Exchange goes sectors. In fact, 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 if necessary and work with files on fixed numbers - again, this is done in this implementation, 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 ID is used as a token for the fact that the server was restarted and forgot the file numbers. In such a situation, the session identifier will show a mismatch and the client will receive an error, which must be processed by re-requesting the file number for the given name again. However, I did not write this part of the protocol, as I myself do not need it yet.
The protocol is lightweight in terms of implementation so that even the server can be pushed into a weak microcontroller. And so the client even more so.
The protocol works over UDP. Use on health, if required. With all the simplicity due to asynchrony and out of order, the resend protocol is quite effective. Only if orderly execution of requests is needed - this must be ensured outside. TRFS itself will happily perform in the order of the arrival of responses over the network.
TCP FS
There is one more thing that does not exist in modern Unix and which I want to have in the unix box phantom. It is as simple as mooing, and why no one did it is incomprehensible:
')
#cat /tcp/host/port > local_file True, I want to use a different syntax for the file name, the URL style is tcp: // host: port, but these are details. Naturally, along with TCP, UDP is requested, and there are no problems at all.
Spoiler header
In general, the phantom 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 a listen or connect, but it can be solved by specifying a certain suffix in the name of the “file”.
There is so much more to say on this subject that we will proceed without stopping to the next one.
TRFS is a trivial remote file system.
In one of the test environments Phantom worked on a machine without a disk and wanted to organize remote paging over the network. For this, I made a minimal network FS.
References:
The protocol is reminiscent of tftp oak, but asynchronous - the request does not have to wait for a response synchronously, instead, the client sends requests without waiting and shame, can receive answers separately and re-request the time not received.
Exchange goes sectors. In fact, 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 if necessary and work with files on fixed numbers - again, this is done in this implementation, 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 ID is used as a token for the fact that the server was restarted and forgot the file numbers. In such a situation, the session identifier will show a mismatch and the client will receive an error, which must be processed by re-requesting the file number for the given name again. However, I did not write this part of the protocol, as I myself do not need it yet.
The protocol is lightweight in terms of implementation so that even the server can be pushed into a weak microcontroller. And so the client even more so.
The protocol works over UDP. Use on health, if required. With all the simplicity due to asynchrony and out of order, the resend protocol is quite effective. Only if orderly execution of requests is needed - this must be ensured outside. TRFS itself will happily perform in the order of the arrival of responses over the network.
Source: https://habr.com/ru/post/282808/
All Articles