I have been implementing a communication protocol which
is based on the CAN. The protocol occupies the application
and the transport layer in the OSI model. I have never
implemented any communication protocol yet so I have tried
to solve that with a minimal experiences. I am now facing the
need to extend my current implementation and I have found
that it is very difficult. So I have doubts that my solution
isn't appropriate. I would like to ask you for any book,
document or website where I can find any tips or recommendations
for the beginers like me. Thanks in advance for anything.
Kind of specific to CAN, and probably assumes that you know some basics, but may be useful: "Controller Area Network: Basics, Protocols, Chips and Applications", Prof. Dr.-Ing. K. Etchberger, IXXAT, 2001.
For a more general book, look for something with a title like "Computer Communications" or "Data Communications" -- that should teach all the basics.
to my opinion, one of the best references about protocol stack *implementation* in general (not specifically related to CAN) is still part IV of the book "Design and Implementation of the 4.4 BSD Operating System" by McKusick, Bostic, Karels, and Quarterman.
Concerning protocol *design*, I would refer to scientific literature instead, also depending on the kind of protocol you are thinking about. It is a very vast and complex topic. A good starting point may be some course material once published online by Dr. Rührup, University of Freiburg, it had plenty of useful references. I hope it is still available.
I also agree with others that designing and developing your own custom protocol may be quite tricky and time consuming. It should only be done after looking at what is already available.
As already mentioned, this is a very general question with no background context, so providing any specific suggestions is guesswork.
Are you dealing with a point-to-point link between two nodes, or with 3 or more nodes? In the latter case you most likely need a way to define unique node addresses. Is there a notion of a single master and slave(s) ala MODBUS? If you have multiple nodes able to initiate communication at any time, you have the possibility of collisions which must be handled correctly in hardware. If your messages are longer than can be contained in a single message object you have to handle message fragmentation and reassembly.
Building a completely general network protocol on top of CANbus is a large undertaking, again as already mentioned. If this is where you are headed, it makes sense to seriously consider an established protocol like CANopen. You would probably learn a lot taking a deep dive into CANopen, it is always instructive to see how other experienced and clever designers have solved such a problem. A proprietary scheme makes more sense if you are able to "rig the game" by defining the problem in such a way that you eliminate much of the complexity inherent to a general scheme.
To amplify: use someone else's protocol if it'll fit, because it'll be hugely less work. Only if you're doing something really specific, or if you're purposely burning time to teach yourself, should you roll your own.
thank you for your reactions. Excuse me for vague description. My task is to implement dedicated communication protocol which was developed by someone else. My task is to prepare the messages, divide the messages into packets and send them on the CAN bus via prepared CAN driver. On the receiving side I have to gather packets and build a message from them, test by CRC calculation the validity of the message and decode the content of the message. I have done all my best but I have almost no experiences with this so I would like to compare my solution with some experienced programmer. Unfortunatelly I haven't found any "design patterns" or any recommendations for beginners. I have doubts that my solution is extendable with difficulties.
Wow, you have my sympathy here, assignments where someone else has done the conceptual work and you get to finish it can be difficult. It really depends on how clean and solid the conceptual work is. Issues discovered during implementation and debug can ripple back up to the conceptual level. I've learned to be at least a little nervous when someone says, "All you have to do is ..."
So, it sounds like you are fragmenting a message with a defined format into small pieces that can be sent in CAN message objects. Is your CAN topology just 2 nodes (point to point) or does it consist of 3 or more nodes? Can any node send a message to any other node? Assuming that you have 3 or more nodes and messages can be sent from any node to any other node, has a method been defined for node addressing? If multiple nodes are allowed to autonomously originate messages, you probably need some notion of CAN arbitration and bus ownership if you don't use message identifier and mask to qualify reception based on node address. Even so, you have to handle the case where two or more nodes attempt to send a message to the same destination at the same time.
With regard to fragmentation, you might consider using part of your message object to manage fragmentation and reassembly, and the remaining bytes for fragment data payload. In the management byte(s) you might consider a fragment number (0 could imply first fragment), a last fragment bit, and a message sequence number that increments with each message on a modulo boundary. You might also consider a fragment data byte count to cleanly deal with a "runt" payload in the last fragment.
Reception might be stateful based on fragment number, reset by timeout or by reception of fragment 0, ignoring fragments that don't have the expected message sequence number or next fragment number unless starting a new message in fragment 0.
I hope this helps a little, I am taking relatively blind stabs at what might be useful to you.
You need to tell us a lot more about your application and why you think you might need to roll your own higher level protocol.
It might be worth studying the CANopen protocol
I've used my own on several occasions but it may not be the best place to start.