We know that a protocol is a rule that computers follow so that they can effectively communicate with each other.
But when we talk about rules, the question arises, what are these rules.?
For example, let's take the http protocol. What rules does it have on which computer follows?
I will now list some of the rules, and if it’s wrong, please correct me and tell me whether they are rules in general or not.
For example http protocol ...
this protocol dictates such rules ..
1.determines on which method (GET, POST and then) the request will be sent.
2. on which host the request will be sent.
3. what format will be requested file.
4.which data cookie will be sent to the server
5. on which port the request will be sent
etc....
when we talk about TCP protocol ...
this protocol dictates such rules ..
1.It records on which port the data will be sent.
2.data is divided into packets and a number is assigned to each packet so that the computer that receives the data will correctly arrange the packets.
3. When a packet is lost on the road, it has rules to send the request again to get the lost packet.
etc....
when we talk about the IP protocol ...
this protocol dictates such rules ..
1.This protocol provides source and destination ip addresses and decides on which routers packets should go. routers work at this level.
etc....
Please confirm if I understand correctly, do these rules represent a protocols or not??
Communication protocols need to define everything needed for two separate software developers to write two separate pieces of software that are able to communicate to each other using that protocol.
This includes things like the context in which the protocol is expected to operate, the various protocol states (e.g. the TCP state machine), the expected behavior in each state, how transitions between the states work, how messages are encoded, and what is the precise meaning of each message is.
Your examples are on the right track, but I suggest you skim at lest some of the initial RFCs for the protocol you mentioned like IP and TCP. They're fairly readable and will give you a better idea of what's need to define a protocol.
Related
We use Autosar to implement automotive gateway, and the PDUR module can be configured to route message from one interface to other protocol interfaces.
My question is if we want to do message check, analysis or logging, how could we know what message routed by PDUR? should I configure all the message transfer to SW-C application layer for analysis or is there any other method to do above deep message inspection feature.
Thanks
Jack
When I hear analysis and logging, I already get bad headache, because of features, that are put into ECUs but rather should be tested with proper stress tests from outside, e.g. PDUs on network A is seen on network B after whatever milliseconds. For such logging, you usually need a EEPROM or FLASH with a certain P/E cycles, which will just add to the price of the ECU without much benefit. And it also impacts your ECUs performance.
Regarding PduR message based routing, you should be very careful because:
Depending on CanRxProcessing, the handling of the PduR routing is handled on Interrupt level, so your "deep message checks" increase your ISR runtime/locktime!
Certain features in Can and CanIf (and also other bus specific network components) might already discard received messages, so PduR might not even be informed about it (e.g. static DLC check, message in BasicCAN HRH is blocked by SW filtering)
Some messages might not be routed by PduR directly, like signal based routing is actually handled in Com not in PduR, maybe protocols are routed by protocol specific modules and not by PduR
CanTp can have multiple addressing formats, where the N_TA is in the first data byte. Here it is tricky to handle multiple connections, if you think about certina N_TAs not being routed
Not sure about SecOC, is the gateway only routing authenticated messages?
Some routed messages could be disabled/enabled on the fly (Routing path groups)
Routed messages from network to network usually have a so called routing relationships (Routing paths). In the end, there should be a table somehow, but this depends also on your implementation, e.g. Vector, ETAS, Elektrobit, ...
So, my opinion is, that deep message check, I don't see what you would gain at all here, in the ECU. I would rather prefer a proper Stress Test with certain tooling from the outside.
I am designing an application that communicates with devices over various connection types / transport mechanisms. For example, USB Virtual COM, serial port, and TCP connections. In each case I will be using a custom/device-specific application protocol (e.g. to send commands, receive data, etc.) passed through the underlying transport. For the cases mentioned so far it seems pretty clear to me that the "Application Protocol" is the proprietary command/response one and TCP connection (or serial port or "whatever magically transports the bytes") is the Transport Protocol.
However, what is the best way to talk about intermediate protocols, for example, when encapsulating the aforementioned proprietary application layer protocol inside of another application layer protocol like SSH, HTTP, or SSL/TLS?
This answer to a different question suggests that:
It's not so important what you call it (with which OSI layer it is associated)
Something like this might be correctly described as an application layer protocol that happens to have another application layer protocol built on top of it.
Bottom line: How should I label this detail in the GUI? Perhaps one of the following?
✔ "Tunnel" or "Tunneling Protocol" (as suggested by #EJP)
Other possibilities included:
"Application protocol" (misleading because there is actually a higher level protocol that would be more appropriately given this name)
"Transport protocol" (may be misleading since there would be a lower level protocol like TCP underneath, which is usually what this name would make me think of)
"Encapsulation" or "Encapsulation protocol"
"Wrapping protocol" (similar to above)
"Underlying protocol" (vague / ambiguous -- there are probably many more underlying protocols...TCP, IP, Ethernet, ...)
"Protocol" (too generic?)
Nothing seems to jump out at me as fitting.
Update: As #EJP pointed out, SSL/TLS is an application layer protocol not a transport protocol; the question now reflects this.
However, what is the best way to talk about intermediate protocols, for example, when encapsulating the aforementioned proprietary application layer protocol inside of another application layer protocol like SSH or HTTP or even another transport layer protocol like SSL/TLS?
Every protocol you have mentioned here is an application layer protocol.
You might want to use the word 'tunnelling'.
It's not so important what you call it (with which OSI layer it is associated)
There's no reason to associate it with any of the OSI layers at all. The OSI model is for the OSI protocol suite, which is defunct, ergo so is the model. It's unfortunate that generations of teachers have taught it as though it was a fundamental law of nature. It isn't. If you're using TCP/IP, it has its own layer model, for example, and even the OSI guys admit that nobody ever knew what went into the presentation layer.
I know that it's an unusual thing to need to do, but I need to specify the SOURCE port to be used in an outgoing http(s) request in iOS. I know that there are many different 'standard' ways to send http(s) requests -- from what I understand the most usual involve NSURLConnection and NSURLSession, but I couldn't see if I can specify the source port. Is it possible to somehow use a socket interface to create the socket and then use this socket with NSURLConnection or NSURLSession?
Or perhaps (as a hack) can one specify the ephemeral port range that my app can use (so I'll restrict it to a range of 5 or 10 ports)?
As a last grasping at straws: is there some ip masquerading or other rules that are available on the iOS device that the app could use to ensure that the source port is correct? (I suppose one could write a process which just does masquerading by hand to the correct fixed port -- essentially write a local http forwarding proxy -- is that my only possibility?)
I don't need any fancy feature or control of these http(s) requests except that they need to come from a certain very narrow range of port numbers.
thanks very much.
If you want to ask why I have such a stupid requirement, please feel free to ask privately -- but don't clutter up this question. THanks!!
I note that just a year ago, iOS: how to get the http connection's source port was asked, but that asked about READING the ephemeral port chosen by the system.
thanks
I have use SNMP v1 and 2c for network discovery of printers by sending broadcast message with community "public" and it works just fine, but when I send broadcast message with version 3 of the protocol I got timeout error.
Do somebody share example of SNMPv3 device discovery?
Thank you.
Two things:
1) Doing a broadcast SNMPv1/v2c is actually not defined to work in the protocol. Cheap implementations will simply respond, as you've found, to any packet it sees that the kernel accepts to the port and not check the address. However, you'll also find some implementations that will not respond to broadcast packets. So that's actually not a surefire discovery mechanism in the first place. (Let alone, many vendors finally got smart and don't have public be the default community name)
2) SNMPv3, on the other hand, is even less likely to work because of how engineID discovery happens within the SNMPv3 protocol. SNMPv3 won't respond with a normal response PDU anyway, as it should respond with a REPORT PDU saying "this is my engineID" and you'd have to respond back with that engineID and the proper USM credentials to access the device.
In short, SNMPv3 was designed for security and there isn't a "public" equivalent any longer. You'd need to know how to access the device and can't just "guess".
Hey SO,
What examples do you know - of protocols initially "handshaking" in UDP, then "conversing" in TCP.
I know there are heaps, I just can't seem to think of any right now.
Specifically, I'm trying to write a Wireshark dissector - for this kind of protocol.
So being able to peek on a similar dissector, seems like a good start.
Would love to hear if you've ever written a stateful Wireshark dissector in LUA.
One example is SIP/Fax.
SIP/SDP setups the session for fax transmission, and then transfers fax/image via TCP/TPKT.
There are several that use both UDP and TCP (see Apple's list, marked as TCP/UDP), but I don't know if they behave exactly as you've described (initial handshake with UDP). DNS and NFS are a couple examples.
I've written Wireshark dissectors in Lua, but not stateful ones.
Surely a handshake would be in TCP being a stateful connection? A handshake seems like something that would want to be ordered, compared to UDP where there is stateless transmission?
I've added some kind of statefulness for the HTTP protocol within my project aimed to lookup original HTTP request for given HTTP response.
Generally speaking, Lua has nice notion of closures which can be used as kind of static global variables for holding handshakes and whatever other references.