1.4 KiB
1.4 KiB
# katex
title: >-
Peer Socket
sidebar: false
notmine: false
...
::: myabstract
[abstract:]{.bigbold}
Most things follow the client server model, so it makes sense to have a distinction between server
sockets and client sockets. But ultimately what we are doing is passing messages between entities
and the revolutionary and subversive technologies, bittorrent, bitcoin, and bitmessage are peer to
peer, so it makes sense that all sockets, however created wind up with same properties.
:::
# factoring
In order to pass messages, the socket has to know a whole lot of state. And in order handle messages,
the entity handling the messages has to know a whole lot of state. So a socket api is an answer
to the question how we factor this big pile of state into two smaller piles of state.
Each big bundle of state represents a concurrent communicating process. Some of the state of this
concurrent communicating process is on one side of our socket division, and is transparent to
one side of our division. The application knows the internals of the some of the state, but the
internals of socket state are opaque, while the socket knows the internals of the socket state, but
the internals of the application state are opaque to it. For each of them, it is a pointer. For the
socket code, a pointer to void, for the application code, a pointer to the opaque class peer::socket
$$\lfloor{(h-1000)/4096}\rfloor*4096$$