API This search result can also be retrieved as XML. Click the API icon to see this page as XML.
re-crawl url

Notes on meshchat | cel's hyperboria site

id
HOZcU7YZA2pc
host_id_s
YZA2pc
sku
http://[fc56:8313:1e14:1a50:c01:850:a53e:7127]/meshchat.html
host_s
[fc56:8313:1e14:1a50:c01:850:a53e:7127]
url_chars_i
60
url_protocol_s
http
url_paths_count_i
0
url_file_name_s
meshchat
url_file_ext_s
html
content_type
text/html
crawldepth_i
1
collection_sxt
robot_autocrawlShallow
title
Notes on meshchat | cel's hyperboria site
last_modified
2018-07-30T07:10:01Z
dates_in_content_count_i
1
dates_in_content_dts
2015-05-08T00:00:00Z
http_unique_b
true
www_unique_b
false
exact_signature_l
-5304674660572000142
exact_signature_unique_b
true
fuzzy_signature_l
3840331262671248175
fuzzy_signature_unique_b
true
h1_txt
Notes on meshchat
h2_txt_0
Multiple multicast services
h2_txt_1
Requirements for multicast channels
h2_txt_2
Event loop
h2_txt_3
Scalability
h2_txt_4
References
h3_txt_0
Broadcast over cjdns
h3_txt_1
Multicast
h3_txt_2
Embedded IRC server
h3_txt_3
Example servers to build on (2) alongside the IRC server
h4_txt
Comments
bold_txt
Last updated 2015-05-08
imagescount_i
0
responsetime_i
462
text_t
Notes on meshchat | cel's hyperboria site. ← cel's hyperboria site Notes on meshchat. meshchat tries to do many things at once and doesn't do a great job of any of them. Here are my notes on what I would like to do with meshchat. Restructure into three parts:. Broadcast over cjdns. Use cjdns's admin port and routing table to get IPs. Ping them discover to peers. This is implemented. Decide on how to handle channel (un)reliability. Use heartbeats? The join messages in (2) don't need in-order delivery or at-most-once delivery, but they should probably have guaranteed to nodes that are online. Multicast. Use the broadcast layer (1) to implement named multicast groups. To join a group, a node sends a broadcast message that it wants to join a group of a given name. Peers receiving it note that that peer is in that group and that ack with whether or not they are also in the group. Messages sent to the group should have guaranteed (in-order?) delivery, so they would need sequence numbers, acks, and retransmissions. Use NACK suppression as in Scalable Reliable Multicast. [1] to reduce sender flooding in case of negative acknowledgments, and also find new peers. Embedded IRC server. This is implemented but is buggy. It should be restructured to be one of potentially many services on top of the multicast layer (2). Multiple multicast services. Applications other than IRC servers could benefit from the multicast platform (2). If (1) and (2) are packaged as a library, then each application using them would have to do its own peer discovery and duplicate the work needed to form the network. Therefore, separate out (1) and (2) into a system service and implement a client library to communicate with it over e.g. named pipes. Example servers to build on (2) alongside the IRC server. torrent tracker. ADC hub. mumble server. Requirements for multicast channels. Each of these multicast services may have different requirements for the channel. For example, in an audio/video server, dropping frames may be acceptable rather than buffering, so guaranteed packet delivery might not be necessary. However, for chat or file sharing guaranted delivery is desirable. In-order delivery may be desirable for file transfer but not as important for real-time chat. Consider allowing a multicast peer to send datagrams as well as communicate over a reliable stream, according to the needs of the application. Event loop. Consider using the event loop in openwrt's libubox instead of libuv, so as to have a smaller footprint. Scalability. A tree-based multicast protocol would be more scalable, as nodes would then be able to send a message to a multicast group by sending it to a subset of the members of the group. However, if nodes relay messages sent by other nodes, then we lose the identity guarantees of cjdns packets. This could be handled by exposing a message signing API from cjdns, or by adding another layer of keypair identities so that packets could be signed, forwarded, and verified. Because of the complexity and overhead of this, let's just do many-to-many multicast. References. A Reliable Multicast Framework for Lightweight Sessions and Application Level Framing - Floyd, Jacobson, et al. - 1995. An API for Scalable Reliable Multicast - Jim Gemmell, Jörg Liebeherr, Dave Bassett - 1997. A negative acknowledgement with periodic polling protocol for multicast over lans - Ramakrishnan, Jain - 1987. Last updated. 2015-05-08. Comments.
wordcount_i
567
linkscount_i
6
linksnofollowcount_i
0
inboundlinkscount_i
2
outboundlinkscount_i
4
inboundlinks_urlstub_sxt_0
[fc56:8313:1e14:1a50:c01:850:a53e:7127]/.
inboundlinks_urlstub_sxt_1
[fc56:8313:1e14:1a50:c01:850:a53e:7127]/meshchat.html
inboundlinks_anchortext_txt_0
cel's hyperboria site
inboundlinks_anchortext_txt_1
[1]
outboundlinks_protocol_sxt
000-https
outboundlinks_urlstub_sxt_0
github.com/clehner/meshchat/
outboundlinks_urlstub_sxt_1
www.icir.org/floyd/papers/srm_ton.pdf
outboundlinks_urlstub_sxt_2
www.comm.toronto.edu/~jorg/archive/papers/srm_api7.pdf
outboundlinks_urlstub_sxt_3
citeseerx.ist.psu.edu/showciting;jsessionid=92D2E5EF9D81B7B8DFF04DD79E4F2B19?cid=1084388
outboundlinks_anchortext_txt_0
meshchat
outboundlinks_anchortext_txt_1
A Reliable Multicast Framework for Lightweight Sessions and Application Level Framing
outboundlinks_anchortext_txt_2
An API for Scalable Reliable Multicast
outboundlinks_anchortext_txt_3
A negative acknowledgement with periodic polling protocol for multicast over lans
charset_s
UTF-8
httpstatus_i
200
load_date_dt
2019-05-19T02:04:24.220Z
fresh_date_dt
2019-10-12T11:31:35.830Z
referrer_id_s
CQxUc7YZA2pc
language_s
en
size_i
5170
audiolinkscount_i
0
videolinkscount_i
0
applinkscount_i
0
references_i
2
references_internal_i
2
references_external_i
0
references_exthosts_i
0
host_extent_i
-1
_version_
1633924115825950720