Implement the client half of the CurveCP protocol.
It seems like it would be nice if I could just declare the message exchange, but that approach gets complicated on the server side. At least half the point there is reducing DoS.
Implement the client half of the CurveCP protocol. It seems like it would be nice if I could just declare the message exchange, but that approach gets complicated on the server side. At least half the point there is reducing DoS.
Handle the inherently stateful pieces associated with the client side of things.
The fact that this is so big says a lot about needing to re-think my approach
Handle the inherently stateful pieces associated with the client side of things. The fact that this is so big says a lot about needing to re-think my approach
Translation of curvecpmessage.c
This is really a generic buffer program
The "parent" child/server reads/writes to pipes that this provides, in a specific (and apparently undocumented) communications protocol.
This, in turn, reads/writes data from/to a child that it spawns.
I keep wanting to think of this as a simple transducer and just skip the buffering pieces, but they (and the flow control) are really the main point.
Translation of curvecpmessage.c This is really a generic buffer program The "parent" child/server reads/writes to pipes that this provides, in a specific (and apparently undocumented) communications protocol. This, in turn, reads/writes data from/to a child that it spawns. I keep wanting to think of this as a simple transducer and just skip the buffering pieces, but they (and the flow control) are really the main point.
Cope with flow-control algorithms
Cope with flow-control algorithms
Top-level message helpers
Top-level message helpers
Track active message loops
Track active message loops
Common specs that are shared among message namespaces
Common specs that are shared among message namespaces
No vars found in this namespace.
Looks like this may not be needed at all
Pretty much everything that might have been interesting really seems to belong in from-parent.
Or in the callback that got handed to message as part of its constructor.
Although there is the bit about closing the pipe to the child at the bottom of each event loop.
Looks like this may not be needed at all Pretty much everything that might have been interesting really seems to belong in from-parent. Or in the callback that got handed to message as part of its constructor. Although there *is* the bit about closing the pipe to the child at the bottom of each event loop.
Implement the server half of the CurveCP protocol
Implement the server half of the CurveCP protocol
For dealing with cookie packets on the server side
For dealing with cookie packets on the server side
For coping with incoming HELLO packets
For coping with incoming HELLO packets
Utility functions that are generally useful for Curve servers
Utility functions that are generally useful for Curve servers
For coping with Initiate packets
This is the part that possibly establishes a 'connection'
For coping with Initiate packets This is the part that possibly establishes a 'connection'
No vars found in this namespace.
Managing CurveCP server state
Managing CurveCP server state
For pieces shared among client, server, and messaging
For pieces shared among client, server, and messaging
Shared functions for fiddling with bits
Shared functions for fiddling with bits
Manage child ioloops
Manage child ioloops
Magical names, numbers, and data structures
Magical names, numbers, and data structures
Wrap up the low-level crypto functions
Wrap up the low-level crypto functions
Convert native data structures to/from raw bytes for network travel
Convert native data structures to/from raw bytes for network travel
For specs that make sense to share among all the pieces
For specs that make sense to share among all the pieces
Descriptions of binary files to marshall
Descriptions of binary files to marshall
Pieces refactored from frereth.common.util
Because I haven't really decided what to do with them yet
Pieces refactored from frereth.common.util Because I haven't really decided what to do with them yet
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close