ProtoN (network protocol)
ProtoN (network protocol)
Hi. Didn't posted much stuff here for a long time. Well this one is large enough.
This is my new UDP-based protocol. I had an old need to create something like this, going to use it in some project later (even in some online game, I'm expecting it will be fine for this too).
The concept is something like "TCP-over-UDP" and a bit similar to Google's QUIC protocol (for example, there are others of such type).
Advantages comparing to raw TCP:
- it should be faster/more responsible
- it should be more fault-tolerant (provide faster reaction in cases of packet lost)
- it can work with much lower traffic overhead (TCP overhead is 2.8% minimum, often much higher)
- it is UDP-based, this brings lesser problems with NAT or firewall
Comparing to raw UDP:
- it takes care of packet loss
- provides retransmission mechanism
- provides connection state control/timeouts/keepalive
- all such things that UDP lacks by design
General:
- it's usage is much more reliable than any raw protocol
- it can be customized to fit different tasks (for example, large "session size" is very good to transfer files)
Disadvantages:
- it is software-level protocol, though it is optimized a bit, it anyway consumes much more resources than raw TCP or UDP
- for now I didn't test it in any real project and conditions, only synthetic tests
- there is no encryption at protocol layer. I'm planning RSA+AES, but for now all goes to application responsibility
Implementation:
- a standalone code module
Download:
https://github.com/Lunasole/ProtoN
(oh at last I've started to use modules in my purebasic codes...)
That's all^^ Look at this stuff if interesting.
This is my new UDP-based protocol. I had an old need to create something like this, going to use it in some project later (even in some online game, I'm expecting it will be fine for this too).
The concept is something like "TCP-over-UDP" and a bit similar to Google's QUIC protocol (for example, there are others of such type).
Advantages comparing to raw TCP:
- it should be faster/more responsible
- it should be more fault-tolerant (provide faster reaction in cases of packet lost)
- it can work with much lower traffic overhead (TCP overhead is 2.8% minimum, often much higher)
- it is UDP-based, this brings lesser problems with NAT or firewall
Comparing to raw UDP:
- it takes care of packet loss
- provides retransmission mechanism
- provides connection state control/timeouts/keepalive
- all such things that UDP lacks by design
General:
- it's usage is much more reliable than any raw protocol
- it can be customized to fit different tasks (for example, large "session size" is very good to transfer files)
Disadvantages:
- it is software-level protocol, though it is optimized a bit, it anyway consumes much more resources than raw TCP or UDP
- for now I didn't test it in any real project and conditions, only synthetic tests
- there is no encryption at protocol layer. I'm planning RSA+AES, but for now all goes to application responsibility
Implementation:
- a standalone code module
Download:
https://github.com/Lunasole/ProtoN
(oh at last I've started to use modules in my purebasic codes...)
That's all^^ Look at this stuff if interesting.
Last edited by Lunasole on Sun Apr 05, 2020 7:10 pm, edited 2 times in total.
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
Re: ProtoN (network protocol)
looks interesting, thanks for sharing.
Windows 11, Manjaro, Raspberry Pi OS
Re: ProtoN (network protocol)
Put it on github so you can get some traction ! Looks interesting
Re: ProtoN (network protocol)
Hope the code looks not too terrible to read by someone else ^^ It still needs reviews.
Would be a good idea, but I still have no github in 2020. Maybe somehow laterFred wrote:Put it on github so you can get some traction ! Looks interesting
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
Re: ProtoN (network protocol)
I had just a short look over the code:
You should add the possibillity for the BindIP$ option.
Because if you have more then one network card, you want not always that both cards are listening.
I personally restrict all servers to the address which is really used.
If your procedures using ProcedureReturn, the type of the returnvalue should be specified at Procedure.
(This is also written in the help to Procedure)
I would do it the other way round:
And if you use your module in threads, you should also add a Mutex to lock the list accesses.
Else it is possible that you do 2 concurrent things to the list.
You should add the possibillity for the BindIP$ option.
Because if you have more then one network card, you want not always that both cards are listening.
I personally restrict all servers to the address which is really used.
If your procedures using ProcedureReturn, the type of the returnvalue should be specified at Procedure.
(This is also written in the help to Procedure)
I would do it the other way round:
Code: Select all
Global NewList ProtoNList.PROTON_INSTANCE_IT()
:
*Proton = AddElement(ProtoNList())
If *Proton
:
endif
Else it is possible that you do 2 concurrent things to the list.
Re: ProtoN (network protocol)
Just look a bit deeper inside:
If you use a module, it makes no sense to put the name also in front of the procedures.
It is easier if it is like:
The name in front makes only sense if it is not a module, to unify the name.
In the demo:
You should not use a global variable in the callback.
Better use 2 callbacks.
Or Better:
Then the user can add an own structure with variables inside
And please use
Arround the demo code.
If you use a module, it makes no sense to put the name also in front of the procedures.
Code: Select all
ProtoN::ProtoNTick()
Code: Select all
ProtoN::Tick()
In the demo:
Code: Select all
Case *Connection
Case *Server
Better use 2 callbacks.
Or Better:
Code: Select all
Prototype ProtoNCallback(*Instance.ProtoN::PROTON_INSTANCE, *Link.ProtoN::PROTON_LINK, *Data, nLen, *UserData=#Null)
And please use
Code: Select all
CompilerIf #PB_Compiler_IsMainFile
CompilerEndIf
Re: ProtoN (network protocol)
Yes, that's one of small things to be improved.infratec wrote:I had just a short look over the code:
You should add the possibillity for the BindIP$ option.
Because if you have more then one network card, you want not always that both cards are listening.
Maybe for this will be better to make list and other global variables "Threaded" itself.infratec wrote: And if you use your module in threads, you should also add a Mutex to lock the list accesses.
Else it is possible that you do 2 concurrent things to the list.
Anyway for now it's not "officially" threadsafe.
What about demo it's simple and dirty, for anyone who will use the module it's anyway better to remove the demo part completely.
Maybe later I'll take it to separate file (if will not forget^^).
PS. Generally I'm interesting to move all my stuff to github, as that hosting I'm using is HTTP-only and dramatically outdated.
Looks like github can be used to host it all for free so good idea.
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
- Kwai chang caine
- Always Here
- Posts: 5357
- Joined: Sun Nov 05, 2006 11:42 pm
- Location: Lyon - France
Re: ProtoN (network protocol)
Apparently that work here
Thanks for sharing
Thanks for sharing
The happiness is a road...
Not a destination
Not a destination
Re: ProtoN (network protocol)
GitHub looks fine both for homepage hosting and as a place for some code, I've finally migrated to it^^
Updated link in 1st post + updated code a bit (with some changes mentioned above).
Not sure I really need github for code (as I'm coding in single-mode approximately 100% of all things), but let it be and going to post few more projects sometime.
Updated link in 1st post + updated code a bit (with some changes mentioned above).
Not sure I really need github for code (as I'm coding in single-mode approximately 100% of all things), but let it be and going to post few more projects sometime.
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"