31 lines
1.4 KiB
Markdown
31 lines
1.4 KiB
Markdown
|
---
|
||
|
|
# 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$$
|