Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
S
Statistics Replication
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Iterations
Wiki
Requirements
Jira
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package registry
Container registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
GitLab community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
This is an archived project. Repository and other project resources are read-only.
Show more breadcrumbs
LOFAR2.0
Statistics Replication
Commits
25788373
Commit
25788373
authored
Aug 17, 2021
by
Corné Lukken
Browse files
Options
Downloads
Patches
Plain Diff
Update README.md
parent
7f98e54b
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
README.md
+16
-1
16 additions, 1 deletion
README.md
with
16 additions
and
1 deletion
README.md
+
16
−
1
View file @
25788373
# Statistics
mult
ica
s
tin
g
# Statistics
repl
icati
o
n
We want to fan out an initially UDP stream, from one server to many clients
We want to fan out an initially UDP stream, from one server to many clients
without the origin having to send out the stream multiple times for each
without the origin having to send out the stream multiple times for each
client. Effectively this requires the independent components to replicate the
client. Effectively this requires the independent components to replicate the
stream on behalf of the origin.
stream on behalf of the origin.
## Theory of operations
The program supports two fundamental modes, UDP -> TCP one to many and TCP -> TCP one to many.
In UDP mode the program binds and listens on a UDP port expecting the packets to arrive there. Contrarily, in TCP mode it actively tries
to connect to the remote instead. From here the packets are replicated across all connected TCP clients. Should any of the TCP clients
be to slow in receiving these packets than they will be dropped. The mechanism to drop TCP connections is based user configurable
internal buffer (High Watermark). Parameters such as ports, bound interfaces and buffer size are all user configurable through
command line parameters.
If this program is run in TCP mode it can connect to another instance of itself, allowing to forward data across the network without
requiring the origin to sent packets twice (such as is the case with proxies).
Each received packet is sent as is to all clients, the behavior of multipart packets is not validated and tested.
## Solutions
## Solutions
-
Haproxy
-
Haproxy
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment