Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It appears to me you are slightly confused. Yes, software engineering literature talks about the server/client model and contrasts it with other models, such as peer-to-peer. However, at their core, distributed systems always end up using a server/client model somewhere, because there really is no other way to communicate through the Internet.</p> <p>(Technically, you should be able to send any kind of IP datagrams through the Internet, so you could attempt to invent a different transport protocol that isn't server/client at its core, but I'm assuming you do not want to install new transport layers into the networking stacks of the OSes, plus, there's other gotchas such as home NAT appliances that might be in the middle that would thwart such communication.)</p> <p>How can the two nodes "decide between themselves" who is going to listen and who is going to connect if you're restricting all kind of communication from the get go? You can only reliably use two protocols through the Internet: UDP and TCP. Both of them involve a process setting up a listening socket and the other sending a message (UDP) or performing a connection attempt (TCP) to said listening server.</p> <p>Your idea of doing UDP messages before establishing the connection doesn't really change anything. A process listening to UDP messages is still a server. If anything, it just means that additionally to either listening to or initiating a TCP connection, all the nodes will have to be UDP listening servers as well.</p> <p>You will need to have a third-party message broker of some kind if you do not want to have any kind of listening sockets in the peers before the handshaking happens. This is obvious, because you can't communicate without listening sockets, so you can't perform said handshake to begin with. Catch-22.</p> <p>There's also the obvious solution: make each peer listen to connections, then when two peers want to talk to each other, make both attempt to connect to each other: if neither can connect, report that neither peer is able to function as a server. If one can connect, proceed as normal. If both can connect, discard the second connection and continue using the first connection.</p> <p>My suggestion would be for you to look into how protocols like BitTorrent function (they function quite similarly to the solution I detailed above). Optionally, after you've figured this out, you might want to look into NAT traversal solutions such as <a href="http://en.wikipedia.org/wiki/STUN" rel="nofollow">STUN</a> to ensure you don't run into the "neither peer can be a server" situation as often, but that's a separate issue.</p>
    singulars
    1. This table or related slice is empty.
    1. POConnect two TCP sockets without defining client/server role
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USmpontes
    1. USmpontes
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYes and no ;) I know that I have to use the client/server concept on the core, but the framework should hide this completely to the end user (which other approaches like RPC, Webservices do not). But you are right latter part, I never thought my idea (which came while writing the question) so far that I need a listing socket on each peer to do a auto discovery of client/server :) So the real problem is how to solve this "double connection problem" which seems not this easy for me in an async context.
      singulars
      1. PO
      1. USschlamar
    2. COUpdated the question.
      singulars
      1. PO
      1. USschlamar
    3. CODoesn't seem particularly hard to solve to me. Make each peer be identified by some kind of ID (unique ID, hostname:port pair, doesn't matter) and have each node keep state on which nodes they already have connections to. Note that, like @Mike-Steder is talking about, the real problem here is peer discovery, not connecting two peers once they both know about each other. It seems to me you're looking at this problem with the wrong assumptions. If you're assuming every node knows about all the other nodes right from the beginning, it's not much of a distributed system.
      singulars
      1. PO
      1. USmpontes
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload