Must an application-layer protocol exist for communication between any two programs using sockets?
When any two programs, no matter how simple or complicated, communicate by internet domain sockets (or Unix domain sockets), does it necessarily imply that there is an application-layer protocol for their communication?
Can such an application-layer protocol be either well known and defined (such as HTTP) or ad hoc (without being defined explicitly)?
For example, psql
and postgresql server
communicate by unix or internet domain sockets, and Virtual Machine Manager and KVM/QEMU communicate by unix or internet domain sockets. I was wondering if programs like them necessarily communicate using their own protocols.
This will help me to understand the concept of a protocol (an application-layer protocol in particular).
Thanks.
socket unix-sockets protocols
add a comment |
When any two programs, no matter how simple or complicated, communicate by internet domain sockets (or Unix domain sockets), does it necessarily imply that there is an application-layer protocol for their communication?
Can such an application-layer protocol be either well known and defined (such as HTTP) or ad hoc (without being defined explicitly)?
For example, psql
and postgresql server
communicate by unix or internet domain sockets, and Virtual Machine Manager and KVM/QEMU communicate by unix or internet domain sockets. I was wondering if programs like them necessarily communicate using their own protocols.
This will help me to understand the concept of a protocol (an application-layer protocol in particular).
Thanks.
socket unix-sockets protocols
Sockets are similar to RS-232 ( old tech guy here, who lamented the loss of 25 pin serial ports ) in that there's a method to pass data, but how that data is used is up to the implementer. There are simple examples included in the manual page of a program by the name ofsocket
... not to be confused with the man page of "socket()" ... one example is a one line:socket -wslqvp "echo Socket! " 1938
... for the server, and then connect via:socket -v localhost 1938
... which outputsSocket!
and exits.
– RubberStamp
15 hours ago
Well, unlike internet socket, for unix domain socket, there's no other layers(no data packaging/unpackaging overhead for IPC). And UDS might be used to transfer some thing like crendential or file descriptor, other than pure byte stream, so when you say "application layer", that mostly fit with internet socket.
– 炸鱼薯条德里克
3 hours ago
add a comment |
When any two programs, no matter how simple or complicated, communicate by internet domain sockets (or Unix domain sockets), does it necessarily imply that there is an application-layer protocol for their communication?
Can such an application-layer protocol be either well known and defined (such as HTTP) or ad hoc (without being defined explicitly)?
For example, psql
and postgresql server
communicate by unix or internet domain sockets, and Virtual Machine Manager and KVM/QEMU communicate by unix or internet domain sockets. I was wondering if programs like them necessarily communicate using their own protocols.
This will help me to understand the concept of a protocol (an application-layer protocol in particular).
Thanks.
socket unix-sockets protocols
When any two programs, no matter how simple or complicated, communicate by internet domain sockets (or Unix domain sockets), does it necessarily imply that there is an application-layer protocol for their communication?
Can such an application-layer protocol be either well known and defined (such as HTTP) or ad hoc (without being defined explicitly)?
For example, psql
and postgresql server
communicate by unix or internet domain sockets, and Virtual Machine Manager and KVM/QEMU communicate by unix or internet domain sockets. I was wondering if programs like them necessarily communicate using their own protocols.
This will help me to understand the concept of a protocol (an application-layer protocol in particular).
Thanks.
socket unix-sockets protocols
socket unix-sockets protocols
edited 1 hour ago
炸鱼薯条德里克
521215
521215
asked 16 hours ago
TimTim
27.3k78264473
27.3k78264473
Sockets are similar to RS-232 ( old tech guy here, who lamented the loss of 25 pin serial ports ) in that there's a method to pass data, but how that data is used is up to the implementer. There are simple examples included in the manual page of a program by the name ofsocket
... not to be confused with the man page of "socket()" ... one example is a one line:socket -wslqvp "echo Socket! " 1938
... for the server, and then connect via:socket -v localhost 1938
... which outputsSocket!
and exits.
– RubberStamp
15 hours ago
Well, unlike internet socket, for unix domain socket, there's no other layers(no data packaging/unpackaging overhead for IPC). And UDS might be used to transfer some thing like crendential or file descriptor, other than pure byte stream, so when you say "application layer", that mostly fit with internet socket.
– 炸鱼薯条德里克
3 hours ago
add a comment |
Sockets are similar to RS-232 ( old tech guy here, who lamented the loss of 25 pin serial ports ) in that there's a method to pass data, but how that data is used is up to the implementer. There are simple examples included in the manual page of a program by the name ofsocket
... not to be confused with the man page of "socket()" ... one example is a one line:socket -wslqvp "echo Socket! " 1938
... for the server, and then connect via:socket -v localhost 1938
... which outputsSocket!
and exits.
– RubberStamp
15 hours ago
Well, unlike internet socket, for unix domain socket, there's no other layers(no data packaging/unpackaging overhead for IPC). And UDS might be used to transfer some thing like crendential or file descriptor, other than pure byte stream, so when you say "application layer", that mostly fit with internet socket.
– 炸鱼薯条德里克
3 hours ago
Sockets are similar to RS-232 ( old tech guy here, who lamented the loss of 25 pin serial ports ) in that there's a method to pass data, but how that data is used is up to the implementer. There are simple examples included in the manual page of a program by the name of
socket
... not to be confused with the man page of "socket()" ... one example is a one line: socket -wslqvp "echo Socket! " 1938
... for the server, and then connect via: socket -v localhost 1938
... which outputs Socket!
and exits.– RubberStamp
15 hours ago
Sockets are similar to RS-232 ( old tech guy here, who lamented the loss of 25 pin serial ports ) in that there's a method to pass data, but how that data is used is up to the implementer. There are simple examples included in the manual page of a program by the name of
socket
... not to be confused with the man page of "socket()" ... one example is a one line: socket -wslqvp "echo Socket! " 1938
... for the server, and then connect via: socket -v localhost 1938
... which outputs Socket!
and exits.– RubberStamp
15 hours ago
Well, unlike internet socket, for unix domain socket, there's no other layers(no data packaging/unpackaging overhead for IPC). And UDS might be used to transfer some thing like crendential or file descriptor, other than pure byte stream, so when you say "application layer", that mostly fit with internet socket.
– 炸鱼薯条德里克
3 hours ago
Well, unlike internet socket, for unix domain socket, there's no other layers(no data packaging/unpackaging overhead for IPC). And UDS might be used to transfer some thing like crendential or file descriptor, other than pure byte stream, so when you say "application layer", that mostly fit with internet socket.
– 炸鱼薯条德里克
3 hours ago
add a comment |
2 Answers
2
active
oldest
votes
Yes. Two programs talking to each other must follow some sort of protocol for how that communication should happen. The protocol does not need to be a standard or a formal (as in published, or even written down) protocol, but they must somehow agree on by what means and in what order they should communicate, and what the data that they pass to each other mean.
An analogy is a person exiting a grocery shop by paying for their goods at a check-out counter. There is an agreement of protocol there, and it includes an informal agreement regarding things like what language to use and what currency the monetary transaction should be done in. The protocol also says in what order things need to happen for the person to be able to later exit the store (legally) with the newly bought groceries. This protocol also involves exchange of information necessary for the person to choose whether they are paying using cash or a debit card. Asking to pay with anything else, or asking to pay too early or too late during the check-out process will confuse the person behind the counter, as would speaking in an unknown (incompatible) language.
Sometimes, you break that protocol by wanting to pay by cash at a card-only check-out till. You will then have restart the procedure at a counter that accepts cash. This information was given to you in an early transaction message (a sign saying "debit cards only") that you ignored.
You can see some examples of the protocol messages being sent back and forth between server and client when connecting to an SSH server by ssh
using -vvv
. On the client side, you will see messages about identifying the remote server's SSH protocol version and sending our own client version. There will be messages about agreeing on what ciphers to use and what authentication methods are attempted etc. You may also see the corresponding server side messages if you start the SSH daemon in debug mode and connect to it with a client.
add a comment |
A protocol is just a set way of communication. Nothing else. How strict or how loose they are is another matter.
There's nothing stopping communication from being completely chaotic. You can use netcat
to communicate two endpoints, and the data you send between is restricted only by what is to be achieved by the data exchange. It can be pure nonsense if you want, meaning there's no restriction whatsoever.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502899%2fmust-an-application-layer-protocol-exist-for-communication-between-any-two-progr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes. Two programs talking to each other must follow some sort of protocol for how that communication should happen. The protocol does not need to be a standard or a formal (as in published, or even written down) protocol, but they must somehow agree on by what means and in what order they should communicate, and what the data that they pass to each other mean.
An analogy is a person exiting a grocery shop by paying for their goods at a check-out counter. There is an agreement of protocol there, and it includes an informal agreement regarding things like what language to use and what currency the monetary transaction should be done in. The protocol also says in what order things need to happen for the person to be able to later exit the store (legally) with the newly bought groceries. This protocol also involves exchange of information necessary for the person to choose whether they are paying using cash or a debit card. Asking to pay with anything else, or asking to pay too early or too late during the check-out process will confuse the person behind the counter, as would speaking in an unknown (incompatible) language.
Sometimes, you break that protocol by wanting to pay by cash at a card-only check-out till. You will then have restart the procedure at a counter that accepts cash. This information was given to you in an early transaction message (a sign saying "debit cards only") that you ignored.
You can see some examples of the protocol messages being sent back and forth between server and client when connecting to an SSH server by ssh
using -vvv
. On the client side, you will see messages about identifying the remote server's SSH protocol version and sending our own client version. There will be messages about agreeing on what ciphers to use and what authentication methods are attempted etc. You may also see the corresponding server side messages if you start the SSH daemon in debug mode and connect to it with a client.
add a comment |
Yes. Two programs talking to each other must follow some sort of protocol for how that communication should happen. The protocol does not need to be a standard or a formal (as in published, or even written down) protocol, but they must somehow agree on by what means and in what order they should communicate, and what the data that they pass to each other mean.
An analogy is a person exiting a grocery shop by paying for their goods at a check-out counter. There is an agreement of protocol there, and it includes an informal agreement regarding things like what language to use and what currency the monetary transaction should be done in. The protocol also says in what order things need to happen for the person to be able to later exit the store (legally) with the newly bought groceries. This protocol also involves exchange of information necessary for the person to choose whether they are paying using cash or a debit card. Asking to pay with anything else, or asking to pay too early or too late during the check-out process will confuse the person behind the counter, as would speaking in an unknown (incompatible) language.
Sometimes, you break that protocol by wanting to pay by cash at a card-only check-out till. You will then have restart the procedure at a counter that accepts cash. This information was given to you in an early transaction message (a sign saying "debit cards only") that you ignored.
You can see some examples of the protocol messages being sent back and forth between server and client when connecting to an SSH server by ssh
using -vvv
. On the client side, you will see messages about identifying the remote server's SSH protocol version and sending our own client version. There will be messages about agreeing on what ciphers to use and what authentication methods are attempted etc. You may also see the corresponding server side messages if you start the SSH daemon in debug mode and connect to it with a client.
add a comment |
Yes. Two programs talking to each other must follow some sort of protocol for how that communication should happen. The protocol does not need to be a standard or a formal (as in published, or even written down) protocol, but they must somehow agree on by what means and in what order they should communicate, and what the data that they pass to each other mean.
An analogy is a person exiting a grocery shop by paying for their goods at a check-out counter. There is an agreement of protocol there, and it includes an informal agreement regarding things like what language to use and what currency the monetary transaction should be done in. The protocol also says in what order things need to happen for the person to be able to later exit the store (legally) with the newly bought groceries. This protocol also involves exchange of information necessary for the person to choose whether they are paying using cash or a debit card. Asking to pay with anything else, or asking to pay too early or too late during the check-out process will confuse the person behind the counter, as would speaking in an unknown (incompatible) language.
Sometimes, you break that protocol by wanting to pay by cash at a card-only check-out till. You will then have restart the procedure at a counter that accepts cash. This information was given to you in an early transaction message (a sign saying "debit cards only") that you ignored.
You can see some examples of the protocol messages being sent back and forth between server and client when connecting to an SSH server by ssh
using -vvv
. On the client side, you will see messages about identifying the remote server's SSH protocol version and sending our own client version. There will be messages about agreeing on what ciphers to use and what authentication methods are attempted etc. You may also see the corresponding server side messages if you start the SSH daemon in debug mode and connect to it with a client.
Yes. Two programs talking to each other must follow some sort of protocol for how that communication should happen. The protocol does not need to be a standard or a formal (as in published, or even written down) protocol, but they must somehow agree on by what means and in what order they should communicate, and what the data that they pass to each other mean.
An analogy is a person exiting a grocery shop by paying for their goods at a check-out counter. There is an agreement of protocol there, and it includes an informal agreement regarding things like what language to use and what currency the monetary transaction should be done in. The protocol also says in what order things need to happen for the person to be able to later exit the store (legally) with the newly bought groceries. This protocol also involves exchange of information necessary for the person to choose whether they are paying using cash or a debit card. Asking to pay with anything else, or asking to pay too early or too late during the check-out process will confuse the person behind the counter, as would speaking in an unknown (incompatible) language.
Sometimes, you break that protocol by wanting to pay by cash at a card-only check-out till. You will then have restart the procedure at a counter that accepts cash. This information was given to you in an early transaction message (a sign saying "debit cards only") that you ignored.
You can see some examples of the protocol messages being sent back and forth between server and client when connecting to an SSH server by ssh
using -vvv
. On the client side, you will see messages about identifying the remote server's SSH protocol version and sending our own client version. There will be messages about agreeing on what ciphers to use and what authentication methods are attempted etc. You may also see the corresponding server side messages if you start the SSH daemon in debug mode and connect to it with a client.
edited 15 hours ago
answered 15 hours ago
KusalanandaKusalananda
132k17252416
132k17252416
add a comment |
add a comment |
A protocol is just a set way of communication. Nothing else. How strict or how loose they are is another matter.
There's nothing stopping communication from being completely chaotic. You can use netcat
to communicate two endpoints, and the data you send between is restricted only by what is to be achieved by the data exchange. It can be pure nonsense if you want, meaning there's no restriction whatsoever.
add a comment |
A protocol is just a set way of communication. Nothing else. How strict or how loose they are is another matter.
There's nothing stopping communication from being completely chaotic. You can use netcat
to communicate two endpoints, and the data you send between is restricted only by what is to be achieved by the data exchange. It can be pure nonsense if you want, meaning there's no restriction whatsoever.
add a comment |
A protocol is just a set way of communication. Nothing else. How strict or how loose they are is another matter.
There's nothing stopping communication from being completely chaotic. You can use netcat
to communicate two endpoints, and the data you send between is restricted only by what is to be achieved by the data exchange. It can be pure nonsense if you want, meaning there's no restriction whatsoever.
A protocol is just a set way of communication. Nothing else. How strict or how loose they are is another matter.
There's nothing stopping communication from being completely chaotic. You can use netcat
to communicate two endpoints, and the data you send between is restricted only by what is to be achieved by the data exchange. It can be pure nonsense if you want, meaning there's no restriction whatsoever.
answered 15 hours ago
TomaszTomasz
9,69152965
9,69152965
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502899%2fmust-an-application-layer-protocol-exist-for-communication-between-any-two-progr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Sockets are similar to RS-232 ( old tech guy here, who lamented the loss of 25 pin serial ports ) in that there's a method to pass data, but how that data is used is up to the implementer. There are simple examples included in the manual page of a program by the name of
socket
... not to be confused with the man page of "socket()" ... one example is a one line:socket -wslqvp "echo Socket! " 1938
... for the server, and then connect via:socket -v localhost 1938
... which outputsSocket!
and exits.– RubberStamp
15 hours ago
Well, unlike internet socket, for unix domain socket, there's no other layers(no data packaging/unpackaging overhead for IPC). And UDS might be used to transfer some thing like crendential or file descriptor, other than pure byte stream, so when you say "application layer", that mostly fit with internet socket.
– 炸鱼薯条德里克
3 hours ago