readme explanations
This commit is contained in:
Philippe PITTOLI
parent
7a9101faf1
commit
70dea11ad2
@ -1,41 +0,0 @@
|
||||
# connection init (draft)
|
||||
|
||||
## how things happen
|
||||
|
||||
* Service: daemon providing a feature (windowing, audio, pubsub, …)
|
||||
* Application: specific application (browser, instant messaging, …)
|
||||
|
||||
* service: service name
|
||||
* index: process index (to launch a service several times)
|
||||
* version: service version
|
||||
|
||||
1. Service creates a unix socket /tmp/service-index-version.sock
|
||||
2. Application connects to /tmp/service-index-version.sock
|
||||
|
||||
## pure "networking" view (what should go in the sockets)
|
||||
|
||||
1. Application connects to /tmp/service-index-version.sock
|
||||
1. Service acknowledges (empty message)
|
||||
|
||||
# messages format
|
||||
|
||||
In order to communicate between the application and the service, we use the Type-Length-Value format.
|
||||
This will be used with some conventions.
|
||||
|
||||
## programming, debug
|
||||
|
||||
## overview
|
||||
|
||||
The format will be "type : value".
|
||||
|
||||
The type will be a simple byte :
|
||||
|
||||
* <0 - 15> : control, meta data
|
||||
* <16 - 127> : later use
|
||||
* <128 - 255> : application specific (windowing system, audio system, …)
|
||||
|
||||
index | abbreviation | semantic
|
||||
0 | close | to close the communication between the application and the service
|
||||
1 | message | to send data
|
||||
2 | error | to send an error message
|
||||
3 | ack | to send an acknowledgment
|
||||
109
README.md
Normal file
109
README.md
Normal file
@ -0,0 +1,109 @@
|
||||
# the problem
|
||||
|
||||
End-user applications are huge, with tons of libraries used and are a pain in the ass to maintain.
|
||||
Libraries are huge, with a lot of things happening, with changes that break everything on a regular basis, with almost each time very few people working on it.
|
||||
|
||||
# how to change that ?
|
||||
|
||||
**Network protocols**
|
||||
|
||||
Network protocols are awesome: very few changes, well documented, programming language agnostics.
|
||||
|
||||
Don't (just) write libraries, write applications !
|
||||
|
||||
Your need a functionality in your application, why do you have to code it ?
|
||||
Just ask a service !
|
||||
|
||||
**Example**
|
||||
|
||||
You want to download a file, you will always have the same input: a string corresponding to the file to get, such as _ftp://example.com/file.txt_.
|
||||
You don't have to worry about the protocol to use in your own application, the burden is on the dedicated *downloading* service.
|
||||
|
||||
# benefits
|
||||
|
||||
**Awesome abstractions**.
|
||||
|
||||
You will be able to do things without any code.
|
||||
|
||||
* applications don't have to know if the services they use is on the network or on your own computer
|
||||
* applications don't need to change anything to handle new protocols, no recompilation
|
||||
* applications can be statically compiled, the memory footprint should be extremely low (yes, even for a browser)
|
||||
|
||||
**Simple applications**.
|
||||
|
||||
You only need to code the specific code of your own application.
|
||||
The only thing your application should have to take care is its functionality, and to communicate to services providing abstractions.
|
||||
|
||||
**Consistency**.
|
||||
|
||||
Everything will be developed in the same repository: same coding standards, changes will be tested on every provided applications…
|
||||
|
||||
**Code review**.
|
||||
|
||||
We should always try to provide new abstractions, reducing the code needed in both services and end-user applications.
|
||||
To that end, code review is a must.
|
||||
|
||||
# Application and services
|
||||
|
||||
- Services: daemons providing a feature (windowing, audio, network, input, pubsub, …)
|
||||
- Applications: end-user applications (browser, mail user agent, instant messaging app, …)
|
||||
|
||||
#### examples
|
||||
|
||||
A browser that can download everything, via every existing protocol.
|
||||
No any specific code in the browser itself and no configuration.
|
||||
|
||||
You want to play a game on your rasberry pi, but it is not powerful enough, run your application on your laptop but take the inputs from the rpi (or anywhere on the network) !
|
||||
No specific code needed.
|
||||
|
||||
# TODO
|
||||
|
||||
Figures, a lot of them, to explain everything.
|
||||
|
||||
# connection init (draft)
|
||||
|
||||
## how things happen
|
||||
|
||||
1. Service creates a unix socket /tmp/service-index-version.sock
|
||||
1. Application connects to /tmp/service-index-version.sock
|
||||
|
||||
__legend__:
|
||||
- service: service name
|
||||
- index: process index (to launch a service several times)
|
||||
- version: service version
|
||||
|
||||
# pure "networking" view (what should go in the sockets)
|
||||
|
||||
#### connection
|
||||
1. Application connects to /tmp/service-index-version.sock
|
||||
1. Service acknowledges (empty message)
|
||||
|
||||
#### disconnection
|
||||
1. Application sends a message "CLOSE" to the server
|
||||
|
||||
#### data
|
||||
1. Application or server sends a message "DATA", no acknowledgement
|
||||
|
||||
# messages format
|
||||
|
||||
In order to communicate between the application and the service, we use the Type-Length-Value format.
|
||||
This will be used with some conventions.
|
||||
|
||||
## programming, debug
|
||||
|
||||
## overview
|
||||
|
||||
The format will be "type : value".
|
||||
|
||||
The type will be a simple byte :
|
||||
|
||||
* <0 - 15> : control, meta data
|
||||
* <16 - 127> : later use
|
||||
* <128 - 255> : application specific (windowing system, audio system, …)
|
||||
|
||||
index | abbreviation | semantic
|
||||
0 | close | to close the communication between the application and the service
|
||||
1 | connection | to connect to the service
|
||||
2 | error | to send an error message
|
||||
3 | ack | to send an acknowledgment
|
||||
4 | message | to send data
|
||||
@ -71,7 +71,7 @@ int srv_close_proc (struct process *p)
|
||||
{
|
||||
// struct msg m_ack_dis;
|
||||
// memset (&m_ack_dis, 0, sizeof (struct msg));
|
||||
// m_ack_dis.type = MSG_TYPE_ACK_DIS;
|
||||
// m_ack_dis.type = MSG_TYPE_CLOSE;
|
||||
|
||||
// if (msg_write (p->proc_fd, &m_ack_dis) < 0) {
|
||||
// handle_err ("srv_close_proc", "msg_write < 0");
|
||||
@ -136,12 +136,12 @@ int app_connection (int argc, char **argv, char **env
|
||||
return 0;
|
||||
}
|
||||
|
||||
// send a DIS message then close the socket
|
||||
// send a CLOSE message then close the socket
|
||||
int app_close (struct service *srv)
|
||||
{
|
||||
struct msg m;
|
||||
memset (&m, 0, sizeof (struct msg));
|
||||
m.type = MSG_TYPE_DIS;
|
||||
m.type = MSG_TYPE_CLOSE;
|
||||
if (msg_write (srv->service_fd, &m) < 0) {
|
||||
handle_err ("app_close", "msg_write < 0");
|
||||
}
|
||||
|
||||
@ -5,12 +5,11 @@
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
|
||||
#define MSG_TYPE_CLOSE 0
|
||||
#define MSG_TYPE_CON 1
|
||||
#define MSG_TYPE_DIS 2
|
||||
#define MSG_TYPE_ERR 3
|
||||
#define MSG_TYPE_ACK 4
|
||||
#define MSG_TYPE_DATA 5
|
||||
#define MSG_TYPE_ACK_DIS 6
|
||||
#define MSG_TYPE_ERR 2
|
||||
#define MSG_TYPE_ACK 3
|
||||
#define MSG_TYPE_DATA 4
|
||||
|
||||
struct msg {
|
||||
char type;
|
||||
|
||||
Reference in New Issue
Block a user