簡單Elixir遊戲服設計-關於call仍是cast

 

以前寫了篇關於call仍是cast的討論，實際等要改爲call的時候又發生了疑問。

由於call的確有以下做用：

1. 阻塞客戶端

2. 有返回值能肯定操做是否成功，並能很好的支持測試

3. 保證時序，只有call成功了，才能繼續執行下一步

但是除此以外，還有其餘好處嗎？麻煩呢？

若是table_server 只是爲一個玩家所用，那麼多是合適的。

惋惜不是，table_server 還須要廣播信息，而這部分廣播信息不可能放在玩家進程作，

這樣若是在調用端和被調用端都發消息，就有點冗餘。

cast 是丟過去無論，有返回天然收到，沒有返回的話，對不起你本身看着辦重試（看起來更流暢？）

若是call timeout了，call調用的時候，到底該怎麼處理？

告訴用戶處理失敗？ 後續收到該處理的操做完成又該怎麼告訴用戶？

按照GenServer的文檔說明，調用者要麼崩潰保持乾淨，

要麼就是try catch，並丟棄那些垃圾信息。

胡言亂語，我仍是決定應用call，而且廣播消息只在桌子進程統一發。

最終還整理了simple_table的測試，以及修正Application.start(GameServer) 爲 Application.start(:game_server) 的bug。

暫時到這裏了，一成天都在思考call 和cast，以及思考測試的問題，搞得很疲勞。

如今TableServer沒什麼好測試的，若是像SimpleTable那樣去測試，實在顯得冗餘？

若是不測，又感受不是很可靠的樣子（曾經的elixir項目我是測進程的），也許是第一次採用這種測試分解方法，還不習慣吧。

代碼已經發布，後續接着：

添加不翻牌、不補牌的操做加速牌局

添加玩家的操做

以及補充測試

=====================================新的想法=============================

call 大抵適用於那種call期間無需處理其餘事情的調用。

像遊戲這種，一般中間會有其餘消息須要處理，這時候爲了及時處理更新，call可能就不合適了。

我想這大概就是你們用cast的最大緣由。

引伸開來，若是連cast都顯得緩慢，那可能又須要直接對socket發操做了（固然這是最後選擇）。

我代碼就保持call不改了（棋牌可能影響不大），我也懶得改，這個系列主要是探討總結用的。