How do I create an Internet Protocol?
We are all familiar with popular protocols such as IMAP and POP, which are used to exchange email messages.
I have a plan for a new protocol, but I'm not sure how to implement it.
Is the protocol a collection of C source code, for example, that accepts and sends data over ports? Or is it a protocol, just a detailed description of how the data should be sent, which clients then implement?
I am at a loss where to start here and I am not very good at how the protocol system works.
Edit:
Also, if I am writing a protocol and it is not official by a group of standards, can users / clients implement it?
source to share
The official way is to write an RFC - Request for Comments . People will answer this (why RFC exactly) and will probably try to implement your protocol.
As soon as there are two independent implementations that fully support the protocol, this is a new standard.
Of course, people are not going to implement a new protocol for someone just for fun. Therefore, you must first find a group that is interested in listening to you. Perhaps there is already a protocol out there that does what you want (or could be easily extended).
But you probably don't want to invent a new standard. Standards are a lot of work and, for some, overrated.
So, you have to describe how it works and create a library that can read and write the protocol, so developers can use it even if it's not an official standard.
source to share
You are confusing the protocol standard with the implementation.
These 2 are not related.
The protocol is described at a high level, but it has enough information for someone not to know how to implement it.
The idea is that someone reading the document can figure out how / what to implement in whatever language they prefer
To give an example: the SIP protocol in the RFC describes different streams and also has different messages and how they should be handled b, i.e. well-defined semantics .
You can implement SIP UA or Server in C ++ or Java. This has nothing to do with SIP
You don't need to provide any source code for this (you could if you think it helps clear up some of the ambiguity of the description).
The most important part is that your protocol is actually being validated by stakeholders, that is, people who expect it to solve their problems.
This part is important not only because it can solve problems in your protocol, but also because they can actually verify that the concept is solid, i.e. technically implemented
The only case when it would be possible to indicate something specific or to imply something is, for example, if the protocol describes something that requires certain restrictions, for example. hard real-time constraint that can serve as a "hint" on which implementation / languages avoid
Also, if I am writing a protocol and it is not an official standards group, can people / clients still implement it?
Weird question. What do you have in mind? How does anyone know your protocol exists? If it is official, it can get it from the standards group to implement it.
Otherwise, it is obvious that you have some kind of "proprietary" protocol (which is not uncommon, for example a company might have an internal protocol for its own software) and people need to get the specification from you.
source to share
Since you are interested in the Replace Email section in Paul Graham's article you linked, then IMHO you will need to develop a protocol definition as well as provide an example implementation. A protocol definition does not need to be published as an Internet Protocol Standard to be useful.
You will need an implementation so you can test, refine, and refine ideas. It is highly unlikely that the protocol will be right on the first try and you will need something to keep the initial users alive.
You do not need a protocol definition to implement improved writing, but you do need one if you expect others to work with you and accept it, although this is highly dependent on your "business model". I highly recommend that you have a protocol definition from the start, even if only to keep yourself sane when you try to do the second implementation.
I recommend taking a look at some examples of dastardly protocol and implementation approaches. My favorites are described in the 2008 Forecast Prediction Forecast Report on the Super Compact Approach to TCP / IP.
They did not follow the traditional approach to protocol development (protocol stack). Instead, they wrote code that parsed the human-readable TCP / IP protocol specification and generated the TCP / IP stack code from that protocol document. A typical TCP / IP stack is about 40,000 lines of code or more. Their program, which read the protocol specification and generated the code for the TCP / IP stack "automatically", was only 160 lines of code. They use extremely powerful programming tools.
If you had an approach like this, you could synchronize the protocol implementation with the specification and perhaps make it easy for others to accept your protocol.
HTH
source to share