Re: [閒聊] tmi2-mudlib 的更改
提一下 intermud 的替代方案構想，以底下四個函數為主:
socket_create
socket_connect
socket_write
socket_close
首先弄一台 server 出來，所有 tmi2_v3_改 的站，都可以透過
server 的管理者，提出遠端頻道互連的申請。
接著，假設有 A, B, C 三個 tmi2_v3_改 的站。
當 A 站以遠端頻道的指令，發送出一個訊息時
sent_msg_to_remote_server(msg);
遠端 server 收到該訊息後，就會將這個訊息同時送給 A, B, C
三個站的接收訊息物件，由這個物件進行訊息的廣播，達到從 A
站發送遠端訊息，A、B、C 三站都能接收到訊息的目的，而且..
一、可決定是否接收從某一站過來的訊息或是全部不接收
二、各站可決定是要讓 wiz 或是讓全部玩家皆可發送訊息
三、也可決定是只要讓 wiz 或是讓全部玩家皆可接收訊息
(我一般是希望只有 wiz 之間、甚至只有架站者之間可以)
四、sanc 目前的主機(可信任的 ip 來源)就可當 server
└而且也不一定要 sanc 當 server
五、假設 A 站還有另一個同樣以 tmi2_v3_改 架出來的 A2 站，
A2 站亦可向 server 提出公頻互通申請。
六、理論上 server 端可依各站提出的申請需求，決定自己站發
送出來的訊息，是要全部都能接收到，還是只有一部份可
七、訊息理論上可支援各站自訂的 semote
八、訊息是可被各站自行 log 的
九、使用遠端頻道互通前要向 server 端提出申請，申請時得附
上是哪一個 mud 站(ip + port)要送收訊息。
目前有些缺點，就是送出去的訊息，跟各站實際接收到的訊息可
能會有一些落差，某些特殊字元需再經過特殊處理這樣；另外就
是訊息的傳送也會有一些些的 delay 這樣(大概最長 1 秒多)。
優點就是架構簡單，未來釋出的 tmi2_v3_改 就會內建這樣的東
西，程式段會包在 channeld.c 裡頭並在 /include/intermud.h
宣告一些定義，遠端公頻指令預設為 tmi2(亦可自訂)，下次釋出
的版本就會有。
不曉得大家的意見如何?
laechan
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.224.75.253
※ 文章網址: http://www.ptt.cc/bbs/mud/M.1402497240.A.757.html
推
06/11 22:44, , 1F
06/11 22:44, 1F
這是源自你提出的想法，而我覺得這是 tmi2_v3_改 也應納入的
東西。
預計最快星期五釋出這個版本，並暫時以我的 PC 當 server。
(前提是它當 server 可 work，若不行就不在下次釋出)
※ 編輯: laechan (61.224.75.253), 06/11/2014 22:50:03
推
06/12 10:49, , 2F
06/12 10:49, 2F
上圖是以 sanc 主機當 server 的例子，tmi2_v3_改 的三個
主要檔案是
/adm/daemons/channeld.c
/adm/daemons/logind.c
/include/tmi2_v3_channel.h
然後我在我自己的 PC 上跑兩份 mudos，它們共同使用 lib/
目錄只是 name 及 port 不同，一個是 5000 一個是 6000。
然後當我從 port 5000 那邊下 tmi2 test 的遠端交談指令時
，訊息會先傳到 sanc 主機端，sanc 主機端再將訊息傳送給
所有已註冊的 tmi2_v3_改 的 mud，以目前來說有註冊的就是
架在我 PC 上的 port 5000 及 port 6000 兩個 mud，於是這
兩個 mud 在接收到從 server 端傳來的訊息後，就會將訊息
顯示出來。
它的架構很簡單，原因是因為用了偷吃步的做法，但基本上這
樣做是絕對可以的，因為訊息必須先傳到 server 端，server
端才把訊息送給各 tmi2_v3_改 mud，然後各 mud 亦可透過簡
易的修改，來決定要不要接收訊息、以及要限制只有誰才能接
收訊息。
※ 編輯: laechan (210.61.157.53), 06/12/2014 12:20:17
討論串 (同標題文章)
完整討論串 (本文為第 13 之 27 篇)：
mud 近期熱門文章
PTT遊戲區 即時熱門文章
9
18