How many connections can there be between two Unix domain sockets?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












1















From APUE:




17.3 Unique Connections



A server can arrange for unique UNIX domain connections to clients
using the standard bind, listen, and accept functions. Clients
use connect to contact the server; after the connect request is
accepted by the server, a unique connection exists between the client
and the server. This style of operation is the same that we
illustrated with Internet domain sockets in Figures 16.16 and
16.17.




If I am correct, there can be at most one connection between two internet domain TCP sockets.



How many connections can there be between two Unix domain sockets?



If there is also at most one, why does the book dedicate a section for making connection between two unix domain sockets unique?



Thanks.










share|improve this question




























    1















    From APUE:




    17.3 Unique Connections



    A server can arrange for unique UNIX domain connections to clients
    using the standard bind, listen, and accept functions. Clients
    use connect to contact the server; after the connect request is
    accepted by the server, a unique connection exists between the client
    and the server. This style of operation is the same that we
    illustrated with Internet domain sockets in Figures 16.16 and
    16.17.




    If I am correct, there can be at most one connection between two internet domain TCP sockets.



    How many connections can there be between two Unix domain sockets?



    If there is also at most one, why does the book dedicate a section for making connection between two unix domain sockets unique?



    Thanks.










    share|improve this question


























      1












      1








      1








      From APUE:




      17.3 Unique Connections



      A server can arrange for unique UNIX domain connections to clients
      using the standard bind, listen, and accept functions. Clients
      use connect to contact the server; after the connect request is
      accepted by the server, a unique connection exists between the client
      and the server. This style of operation is the same that we
      illustrated with Internet domain sockets in Figures 16.16 and
      16.17.




      If I am correct, there can be at most one connection between two internet domain TCP sockets.



      How many connections can there be between two Unix domain sockets?



      If there is also at most one, why does the book dedicate a section for making connection between two unix domain sockets unique?



      Thanks.










      share|improve this question
















      From APUE:




      17.3 Unique Connections



      A server can arrange for unique UNIX domain connections to clients
      using the standard bind, listen, and accept functions. Clients
      use connect to contact the server; after the connect request is
      accepted by the server, a unique connection exists between the client
      and the server. This style of operation is the same that we
      illustrated with Internet domain sockets in Figures 16.16 and
      16.17.




      If I am correct, there can be at most one connection between two internet domain TCP sockets.



      How many connections can there be between two Unix domain sockets?



      If there is also at most one, why does the book dedicate a section for making connection between two unix domain sockets unique?



      Thanks.







      linux socket unix-sockets






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 3 at 21:50







      Tim

















      asked Mar 3 at 21:44









      TimTim

      28.3k78269490




      28.3k78269490




















          2 Answers
          2






          active

          oldest

          votes


















          4














          I'm not convinced I like Steffen Ullrich's wording on that topic. Sockets are naturally complex because they are a generalized interface which can be used for a number of very different protocols (See note 1).



          To generalize between different protocols, the sockets interface identifies common features of different protocols:



          • All protocols must have some address mechanism. (See note 1)

          • All data is sent from an address to an address.

          • Two types of protocol are useful to discuss here:

            • Some protocols represent a connection: SOCK_STREAM

            • Some protocols represent a series of messages: SOCK_DGRAM


          SOCK_STREAM protocols are generally very different from SOCK_DGRAM protocols. But within each of these groups, protocols don't differ so much.



          SOCK_STREAM



          • Example: TCP

          • Data arrives in a long stream without any breaks.

          • Data always arrives in the order it was sent

          Connection orientated protocols are always(?) a pair of sockets with data sent between them in a single connection. Connection protocols usually support some form of "listening" socket as well, who's sole purpose is to wait for new connection requests.



          Think of connection orientated sockets as two telephones with a line between them.



          Calling connect() and accept() results in a new connection with two bound sockets (one on each side of the connection).



          SOCK_DGRAM



          • Example UDP

          • Data arrives in the same blocks (messages) it was sent, not mashed into a continuous stream

          • Messages might not arrive in order.

          Datagram orientated protocols are very different. Sockets can be configured to act a little like mail boxes, receiving messages from anywhere. There's no requirement to have a connection. In the case of UDP, any packet sent to the right IP and port from any IP and port will be picked up by the same socket. So you can hold conversations with several different computers through the same socket.



          There is a special meaning for connect() on SOCK_DGRAM sockets.




          If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.




          This does not create a new unique connection. It just limits which messages will be received by this one socket and NOT the socket on the other side.



          The sendto() function allows the program to send a message and specify an address to send it.



          Unix domain sockets



          These come in both flavors (SOCK_STREAM and SOCK_DGRAM) just as internet sockets do (TCP and UDP). So for SOCK_STREAM unix sockets, yes they just have one connection between a pair of sockets. But SOCK_DGRAM unix sockets are different (just as UDP is different from TCP).




          Note 1: Unix sockets are funky because there is no underlying protocol as such, they are a construct of the kernel. The kernel is free to use it's own socket inodes as the addresses mechanism. As mosvy points out this can lead to odd behaviour when you try to determine the address of a unix socket.






          share|improve this answer

























          • 1. unix sockets come in 3 "flavors", not 2, and the one you omit is the most useful, because it preserves message boundaries (like dgram), and it allows multiplexing connections (like stream). 2. unix sockets do not always have an address 3. a listening socket and the multiplexing with accept() is purely an API thing; no wi

            – mosvy
            Mar 4 at 9:09











          • 1) Two types of protocol are useful to discuss here: Didn't say there were only2. 2) Yes they do. You must have an identifier for the end point. I read somewhere that unix sockets use inodes as addresses. Hunting for a reference. 3) A listening socket is implied by the protocols such as TCP (It's not just API). There must be something waiting for the initial SYN packet, ready to send an ACK packet and receive the final SYNACK packet before the new socket (connection) is open.

            – Philip Couling
            Mar 4 at 9:26












          • No, unix sockets that were only connect()ed or those created with socketpair() do not have an address in any shape or form. I won't annoy you with more stuff, since I'm not sure if it is of any use.

            – mosvy
            Mar 4 at 9:28












          • The inode referenced by any open file description (including inet sockets) has nothing to do with the address a socket is bound to (which in the case of a non-abstract unix domain is actually a different device:inode pair -- the thing that is obtained via SOCK_DIAG/UNIX_DIAG_VFS by tools like ss). But let's cut it here, mkay? Instead of telling me that I'm wrong you could've just called getpeername() and getsockname() on any of the socket returned by socketpair().

            – mosvy
            Mar 4 at 9:54












          • I didn't find anything offensive, but I don't have any intention to continue this discussion, since apparently I'm not able to help you.

            – mosvy
            Mar 4 at 10:20


















          1














          1. At most one.

          2. To make a distinction between how you use socket files, and fifo files. Opening a named fifo for writing does not create a unique connection with the reader. (Or vice versa). In other words this is done to contrast with section 15.5, FIFOs.





          share|improve this answer























            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
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504157%2fhow-many-connections-can-there-be-between-two-unix-domain-sockets%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









            4














            I'm not convinced I like Steffen Ullrich's wording on that topic. Sockets are naturally complex because they are a generalized interface which can be used for a number of very different protocols (See note 1).



            To generalize between different protocols, the sockets interface identifies common features of different protocols:



            • All protocols must have some address mechanism. (See note 1)

            • All data is sent from an address to an address.

            • Two types of protocol are useful to discuss here:

              • Some protocols represent a connection: SOCK_STREAM

              • Some protocols represent a series of messages: SOCK_DGRAM


            SOCK_STREAM protocols are generally very different from SOCK_DGRAM protocols. But within each of these groups, protocols don't differ so much.



            SOCK_STREAM



            • Example: TCP

            • Data arrives in a long stream without any breaks.

            • Data always arrives in the order it was sent

            Connection orientated protocols are always(?) a pair of sockets with data sent between them in a single connection. Connection protocols usually support some form of "listening" socket as well, who's sole purpose is to wait for new connection requests.



            Think of connection orientated sockets as two telephones with a line between them.



            Calling connect() and accept() results in a new connection with two bound sockets (one on each side of the connection).



            SOCK_DGRAM



            • Example UDP

            • Data arrives in the same blocks (messages) it was sent, not mashed into a continuous stream

            • Messages might not arrive in order.

            Datagram orientated protocols are very different. Sockets can be configured to act a little like mail boxes, receiving messages from anywhere. There's no requirement to have a connection. In the case of UDP, any packet sent to the right IP and port from any IP and port will be picked up by the same socket. So you can hold conversations with several different computers through the same socket.



            There is a special meaning for connect() on SOCK_DGRAM sockets.




            If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.




            This does not create a new unique connection. It just limits which messages will be received by this one socket and NOT the socket on the other side.



            The sendto() function allows the program to send a message and specify an address to send it.



            Unix domain sockets



            These come in both flavors (SOCK_STREAM and SOCK_DGRAM) just as internet sockets do (TCP and UDP). So for SOCK_STREAM unix sockets, yes they just have one connection between a pair of sockets. But SOCK_DGRAM unix sockets are different (just as UDP is different from TCP).




            Note 1: Unix sockets are funky because there is no underlying protocol as such, they are a construct of the kernel. The kernel is free to use it's own socket inodes as the addresses mechanism. As mosvy points out this can lead to odd behaviour when you try to determine the address of a unix socket.






            share|improve this answer

























            • 1. unix sockets come in 3 "flavors", not 2, and the one you omit is the most useful, because it preserves message boundaries (like dgram), and it allows multiplexing connections (like stream). 2. unix sockets do not always have an address 3. a listening socket and the multiplexing with accept() is purely an API thing; no wi

              – mosvy
              Mar 4 at 9:09











            • 1) Two types of protocol are useful to discuss here: Didn't say there were only2. 2) Yes they do. You must have an identifier for the end point. I read somewhere that unix sockets use inodes as addresses. Hunting for a reference. 3) A listening socket is implied by the protocols such as TCP (It's not just API). There must be something waiting for the initial SYN packet, ready to send an ACK packet and receive the final SYNACK packet before the new socket (connection) is open.

              – Philip Couling
              Mar 4 at 9:26












            • No, unix sockets that were only connect()ed or those created with socketpair() do not have an address in any shape or form. I won't annoy you with more stuff, since I'm not sure if it is of any use.

              – mosvy
              Mar 4 at 9:28












            • The inode referenced by any open file description (including inet sockets) has nothing to do with the address a socket is bound to (which in the case of a non-abstract unix domain is actually a different device:inode pair -- the thing that is obtained via SOCK_DIAG/UNIX_DIAG_VFS by tools like ss). But let's cut it here, mkay? Instead of telling me that I'm wrong you could've just called getpeername() and getsockname() on any of the socket returned by socketpair().

              – mosvy
              Mar 4 at 9:54












            • I didn't find anything offensive, but I don't have any intention to continue this discussion, since apparently I'm not able to help you.

              – mosvy
              Mar 4 at 10:20















            4














            I'm not convinced I like Steffen Ullrich's wording on that topic. Sockets are naturally complex because they are a generalized interface which can be used for a number of very different protocols (See note 1).



            To generalize between different protocols, the sockets interface identifies common features of different protocols:



            • All protocols must have some address mechanism. (See note 1)

            • All data is sent from an address to an address.

            • Two types of protocol are useful to discuss here:

              • Some protocols represent a connection: SOCK_STREAM

              • Some protocols represent a series of messages: SOCK_DGRAM


            SOCK_STREAM protocols are generally very different from SOCK_DGRAM protocols. But within each of these groups, protocols don't differ so much.



            SOCK_STREAM



            • Example: TCP

            • Data arrives in a long stream without any breaks.

            • Data always arrives in the order it was sent

            Connection orientated protocols are always(?) a pair of sockets with data sent between them in a single connection. Connection protocols usually support some form of "listening" socket as well, who's sole purpose is to wait for new connection requests.



            Think of connection orientated sockets as two telephones with a line between them.



            Calling connect() and accept() results in a new connection with two bound sockets (one on each side of the connection).



            SOCK_DGRAM



            • Example UDP

            • Data arrives in the same blocks (messages) it was sent, not mashed into a continuous stream

            • Messages might not arrive in order.

            Datagram orientated protocols are very different. Sockets can be configured to act a little like mail boxes, receiving messages from anywhere. There's no requirement to have a connection. In the case of UDP, any packet sent to the right IP and port from any IP and port will be picked up by the same socket. So you can hold conversations with several different computers through the same socket.



            There is a special meaning for connect() on SOCK_DGRAM sockets.




            If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.




            This does not create a new unique connection. It just limits which messages will be received by this one socket and NOT the socket on the other side.



            The sendto() function allows the program to send a message and specify an address to send it.



            Unix domain sockets



            These come in both flavors (SOCK_STREAM and SOCK_DGRAM) just as internet sockets do (TCP and UDP). So for SOCK_STREAM unix sockets, yes they just have one connection between a pair of sockets. But SOCK_DGRAM unix sockets are different (just as UDP is different from TCP).




            Note 1: Unix sockets are funky because there is no underlying protocol as such, they are a construct of the kernel. The kernel is free to use it's own socket inodes as the addresses mechanism. As mosvy points out this can lead to odd behaviour when you try to determine the address of a unix socket.






            share|improve this answer

























            • 1. unix sockets come in 3 "flavors", not 2, and the one you omit is the most useful, because it preserves message boundaries (like dgram), and it allows multiplexing connections (like stream). 2. unix sockets do not always have an address 3. a listening socket and the multiplexing with accept() is purely an API thing; no wi

              – mosvy
              Mar 4 at 9:09











            • 1) Two types of protocol are useful to discuss here: Didn't say there were only2. 2) Yes they do. You must have an identifier for the end point. I read somewhere that unix sockets use inodes as addresses. Hunting for a reference. 3) A listening socket is implied by the protocols such as TCP (It's not just API). There must be something waiting for the initial SYN packet, ready to send an ACK packet and receive the final SYNACK packet before the new socket (connection) is open.

              – Philip Couling
              Mar 4 at 9:26












            • No, unix sockets that were only connect()ed or those created with socketpair() do not have an address in any shape or form. I won't annoy you with more stuff, since I'm not sure if it is of any use.

              – mosvy
              Mar 4 at 9:28












            • The inode referenced by any open file description (including inet sockets) has nothing to do with the address a socket is bound to (which in the case of a non-abstract unix domain is actually a different device:inode pair -- the thing that is obtained via SOCK_DIAG/UNIX_DIAG_VFS by tools like ss). But let's cut it here, mkay? Instead of telling me that I'm wrong you could've just called getpeername() and getsockname() on any of the socket returned by socketpair().

              – mosvy
              Mar 4 at 9:54












            • I didn't find anything offensive, but I don't have any intention to continue this discussion, since apparently I'm not able to help you.

              – mosvy
              Mar 4 at 10:20













            4












            4








            4







            I'm not convinced I like Steffen Ullrich's wording on that topic. Sockets are naturally complex because they are a generalized interface which can be used for a number of very different protocols (See note 1).



            To generalize between different protocols, the sockets interface identifies common features of different protocols:



            • All protocols must have some address mechanism. (See note 1)

            • All data is sent from an address to an address.

            • Two types of protocol are useful to discuss here:

              • Some protocols represent a connection: SOCK_STREAM

              • Some protocols represent a series of messages: SOCK_DGRAM


            SOCK_STREAM protocols are generally very different from SOCK_DGRAM protocols. But within each of these groups, protocols don't differ so much.



            SOCK_STREAM



            • Example: TCP

            • Data arrives in a long stream without any breaks.

            • Data always arrives in the order it was sent

            Connection orientated protocols are always(?) a pair of sockets with data sent between them in a single connection. Connection protocols usually support some form of "listening" socket as well, who's sole purpose is to wait for new connection requests.



            Think of connection orientated sockets as two telephones with a line between them.



            Calling connect() and accept() results in a new connection with two bound sockets (one on each side of the connection).



            SOCK_DGRAM



            • Example UDP

            • Data arrives in the same blocks (messages) it was sent, not mashed into a continuous stream

            • Messages might not arrive in order.

            Datagram orientated protocols are very different. Sockets can be configured to act a little like mail boxes, receiving messages from anywhere. There's no requirement to have a connection. In the case of UDP, any packet sent to the right IP and port from any IP and port will be picked up by the same socket. So you can hold conversations with several different computers through the same socket.



            There is a special meaning for connect() on SOCK_DGRAM sockets.




            If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.




            This does not create a new unique connection. It just limits which messages will be received by this one socket and NOT the socket on the other side.



            The sendto() function allows the program to send a message and specify an address to send it.



            Unix domain sockets



            These come in both flavors (SOCK_STREAM and SOCK_DGRAM) just as internet sockets do (TCP and UDP). So for SOCK_STREAM unix sockets, yes they just have one connection between a pair of sockets. But SOCK_DGRAM unix sockets are different (just as UDP is different from TCP).




            Note 1: Unix sockets are funky because there is no underlying protocol as such, they are a construct of the kernel. The kernel is free to use it's own socket inodes as the addresses mechanism. As mosvy points out this can lead to odd behaviour when you try to determine the address of a unix socket.






            share|improve this answer















            I'm not convinced I like Steffen Ullrich's wording on that topic. Sockets are naturally complex because they are a generalized interface which can be used for a number of very different protocols (See note 1).



            To generalize between different protocols, the sockets interface identifies common features of different protocols:



            • All protocols must have some address mechanism. (See note 1)

            • All data is sent from an address to an address.

            • Two types of protocol are useful to discuss here:

              • Some protocols represent a connection: SOCK_STREAM

              • Some protocols represent a series of messages: SOCK_DGRAM


            SOCK_STREAM protocols are generally very different from SOCK_DGRAM protocols. But within each of these groups, protocols don't differ so much.



            SOCK_STREAM



            • Example: TCP

            • Data arrives in a long stream without any breaks.

            • Data always arrives in the order it was sent

            Connection orientated protocols are always(?) a pair of sockets with data sent between them in a single connection. Connection protocols usually support some form of "listening" socket as well, who's sole purpose is to wait for new connection requests.



            Think of connection orientated sockets as two telephones with a line between them.



            Calling connect() and accept() results in a new connection with two bound sockets (one on each side of the connection).



            SOCK_DGRAM



            • Example UDP

            • Data arrives in the same blocks (messages) it was sent, not mashed into a continuous stream

            • Messages might not arrive in order.

            Datagram orientated protocols are very different. Sockets can be configured to act a little like mail boxes, receiving messages from anywhere. There's no requirement to have a connection. In the case of UDP, any packet sent to the right IP and port from any IP and port will be picked up by the same socket. So you can hold conversations with several different computers through the same socket.



            There is a special meaning for connect() on SOCK_DGRAM sockets.




            If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.




            This does not create a new unique connection. It just limits which messages will be received by this one socket and NOT the socket on the other side.



            The sendto() function allows the program to send a message and specify an address to send it.



            Unix domain sockets



            These come in both flavors (SOCK_STREAM and SOCK_DGRAM) just as internet sockets do (TCP and UDP). So for SOCK_STREAM unix sockets, yes they just have one connection between a pair of sockets. But SOCK_DGRAM unix sockets are different (just as UDP is different from TCP).




            Note 1: Unix sockets are funky because there is no underlying protocol as such, they are a construct of the kernel. The kernel is free to use it's own socket inodes as the addresses mechanism. As mosvy points out this can lead to odd behaviour when you try to determine the address of a unix socket.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 4 at 11:17

























            answered Mar 4 at 2:35









            Philip CoulingPhilip Couling

            2,2881122




            2,2881122












            • 1. unix sockets come in 3 "flavors", not 2, and the one you omit is the most useful, because it preserves message boundaries (like dgram), and it allows multiplexing connections (like stream). 2. unix sockets do not always have an address 3. a listening socket and the multiplexing with accept() is purely an API thing; no wi

              – mosvy
              Mar 4 at 9:09











            • 1) Two types of protocol are useful to discuss here: Didn't say there were only2. 2) Yes they do. You must have an identifier for the end point. I read somewhere that unix sockets use inodes as addresses. Hunting for a reference. 3) A listening socket is implied by the protocols such as TCP (It's not just API). There must be something waiting for the initial SYN packet, ready to send an ACK packet and receive the final SYNACK packet before the new socket (connection) is open.

              – Philip Couling
              Mar 4 at 9:26












            • No, unix sockets that were only connect()ed or those created with socketpair() do not have an address in any shape or form. I won't annoy you with more stuff, since I'm not sure if it is of any use.

              – mosvy
              Mar 4 at 9:28












            • The inode referenced by any open file description (including inet sockets) has nothing to do with the address a socket is bound to (which in the case of a non-abstract unix domain is actually a different device:inode pair -- the thing that is obtained via SOCK_DIAG/UNIX_DIAG_VFS by tools like ss). But let's cut it here, mkay? Instead of telling me that I'm wrong you could've just called getpeername() and getsockname() on any of the socket returned by socketpair().

              – mosvy
              Mar 4 at 9:54












            • I didn't find anything offensive, but I don't have any intention to continue this discussion, since apparently I'm not able to help you.

              – mosvy
              Mar 4 at 10:20

















            • 1. unix sockets come in 3 "flavors", not 2, and the one you omit is the most useful, because it preserves message boundaries (like dgram), and it allows multiplexing connections (like stream). 2. unix sockets do not always have an address 3. a listening socket and the multiplexing with accept() is purely an API thing; no wi

              – mosvy
              Mar 4 at 9:09











            • 1) Two types of protocol are useful to discuss here: Didn't say there were only2. 2) Yes they do. You must have an identifier for the end point. I read somewhere that unix sockets use inodes as addresses. Hunting for a reference. 3) A listening socket is implied by the protocols such as TCP (It's not just API). There must be something waiting for the initial SYN packet, ready to send an ACK packet and receive the final SYNACK packet before the new socket (connection) is open.

              – Philip Couling
              Mar 4 at 9:26












            • No, unix sockets that were only connect()ed or those created with socketpair() do not have an address in any shape or form. I won't annoy you with more stuff, since I'm not sure if it is of any use.

              – mosvy
              Mar 4 at 9:28












            • The inode referenced by any open file description (including inet sockets) has nothing to do with the address a socket is bound to (which in the case of a non-abstract unix domain is actually a different device:inode pair -- the thing that is obtained via SOCK_DIAG/UNIX_DIAG_VFS by tools like ss). But let's cut it here, mkay? Instead of telling me that I'm wrong you could've just called getpeername() and getsockname() on any of the socket returned by socketpair().

              – mosvy
              Mar 4 at 9:54












            • I didn't find anything offensive, but I don't have any intention to continue this discussion, since apparently I'm not able to help you.

              – mosvy
              Mar 4 at 10:20
















            1. unix sockets come in 3 "flavors", not 2, and the one you omit is the most useful, because it preserves message boundaries (like dgram), and it allows multiplexing connections (like stream). 2. unix sockets do not always have an address 3. a listening socket and the multiplexing with accept() is purely an API thing; no wi

            – mosvy
            Mar 4 at 9:09





            1. unix sockets come in 3 "flavors", not 2, and the one you omit is the most useful, because it preserves message boundaries (like dgram), and it allows multiplexing connections (like stream). 2. unix sockets do not always have an address 3. a listening socket and the multiplexing with accept() is purely an API thing; no wi

            – mosvy
            Mar 4 at 9:09













            1) Two types of protocol are useful to discuss here: Didn't say there were only2. 2) Yes they do. You must have an identifier for the end point. I read somewhere that unix sockets use inodes as addresses. Hunting for a reference. 3) A listening socket is implied by the protocols such as TCP (It's not just API). There must be something waiting for the initial SYN packet, ready to send an ACK packet and receive the final SYNACK packet before the new socket (connection) is open.

            – Philip Couling
            Mar 4 at 9:26






            1) Two types of protocol are useful to discuss here: Didn't say there were only2. 2) Yes they do. You must have an identifier for the end point. I read somewhere that unix sockets use inodes as addresses. Hunting for a reference. 3) A listening socket is implied by the protocols such as TCP (It's not just API). There must be something waiting for the initial SYN packet, ready to send an ACK packet and receive the final SYNACK packet before the new socket (connection) is open.

            – Philip Couling
            Mar 4 at 9:26














            No, unix sockets that were only connect()ed or those created with socketpair() do not have an address in any shape or form. I won't annoy you with more stuff, since I'm not sure if it is of any use.

            – mosvy
            Mar 4 at 9:28






            No, unix sockets that were only connect()ed or those created with socketpair() do not have an address in any shape or form. I won't annoy you with more stuff, since I'm not sure if it is of any use.

            – mosvy
            Mar 4 at 9:28














            The inode referenced by any open file description (including inet sockets) has nothing to do with the address a socket is bound to (which in the case of a non-abstract unix domain is actually a different device:inode pair -- the thing that is obtained via SOCK_DIAG/UNIX_DIAG_VFS by tools like ss). But let's cut it here, mkay? Instead of telling me that I'm wrong you could've just called getpeername() and getsockname() on any of the socket returned by socketpair().

            – mosvy
            Mar 4 at 9:54






            The inode referenced by any open file description (including inet sockets) has nothing to do with the address a socket is bound to (which in the case of a non-abstract unix domain is actually a different device:inode pair -- the thing that is obtained via SOCK_DIAG/UNIX_DIAG_VFS by tools like ss). But let's cut it here, mkay? Instead of telling me that I'm wrong you could've just called getpeername() and getsockname() on any of the socket returned by socketpair().

            – mosvy
            Mar 4 at 9:54














            I didn't find anything offensive, but I don't have any intention to continue this discussion, since apparently I'm not able to help you.

            – mosvy
            Mar 4 at 10:20





            I didn't find anything offensive, but I don't have any intention to continue this discussion, since apparently I'm not able to help you.

            – mosvy
            Mar 4 at 10:20













            1














            1. At most one.

            2. To make a distinction between how you use socket files, and fifo files. Opening a named fifo for writing does not create a unique connection with the reader. (Or vice versa). In other words this is done to contrast with section 15.5, FIFOs.





            share|improve this answer



























              1














              1. At most one.

              2. To make a distinction between how you use socket files, and fifo files. Opening a named fifo for writing does not create a unique connection with the reader. (Or vice versa). In other words this is done to contrast with section 15.5, FIFOs.





              share|improve this answer

























                1












                1








                1







                1. At most one.

                2. To make a distinction between how you use socket files, and fifo files. Opening a named fifo for writing does not create a unique connection with the reader. (Or vice versa). In other words this is done to contrast with section 15.5, FIFOs.





                share|improve this answer













                1. At most one.

                2. To make a distinction between how you use socket files, and fifo files. Opening a named fifo for writing does not create a unique connection with the reader. (Or vice versa). In other words this is done to contrast with section 15.5, FIFOs.






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Mar 4 at 9:51









                sourcejedisourcejedi

                25.6k445110




                25.6k445110



























                    draft saved

                    draft discarded
















































                    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.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504157%2fhow-many-connections-can-there-be-between-two-unix-domain-sockets%23new-answer', 'question_page');

                    );

                    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






                    Popular posts from this blog

                    Peggy Mitchell

                    Palaiologos

                    The Forum (Inglewood, California)