本發明公開了一種麥序控制方法、服務器、客戶端和計算機系統。該方法包括：服務器將用于指示參與第一語音會話的第一客戶端由待發言狀態切換至可發言狀態的第一消息發送給第一客戶端，其中，第一客戶端與服務器在時間軸上同步；服務器將第一客戶端對應的下麥時間通知給第一客戶端或者包括第一客戶端在內的參與第一語音會話的所有成員，用于指示第一客戶端在達到下麥時間時由可發言狀態切換至待發言狀態，其中，下麥時間為時間軸上的由服務器指定的時間點。本發明解決了現有技術中麥序控制邏輯與客戶端的硬編碼分離的設計難以準確地對客戶端的下麥時間進行控制的技術問題。

技術領域

本發明涉及互聯網通信領域，具體而言，涉及一種麥序控制方法、服務器、客戶端和計算機系統。

背景技術

在現有的互聯網通信領域，多人語音/視頻業務是一種基于富媒體的社交業務。在多人語音/視頻業務中，發言順序是相當重要的一項功能。其中，如果沒有設置發言順序的功能，在多人語音/視頻的應用場景下，很容易導致發言順序的混亂，從而影響到用戶的體驗。

現有的語音/視頻聊天工具大多采用麥序模式來解決發言順序的問題。其中，麥序模式所涉及的兩項關鍵特性是：1）上麥時長；2）麥序調整功能。其中，上麥時長通常是用于對參與語音會話的成員的發言時間進行限制，例如，在現有的一些產品中，語音會話中的某一成員獲得發言權限以后，與之對應的用戶可以獲得長達60s的最長的發言時間，而在計時結束后，客戶端會強制退出可發言狀態，表示發言結束。麥序調整功能通常是用于對參與語音會話的成員的發言次序進行調整，例如，可以將其中一個成員的發言次序上移、下移或者置頂，等等。

然而，現有的麥序模式的控制邏輯通常是在客戶端完成的，或者說，麥序控制邏輯通常會被寫入客戶端的硬編碼，例如，對于上麥時間而言，常見的實現方式是將上麥時間固定在客戶端，這導致同一個版本的客戶端上麥時間是相同的，對于上麥時間的修改則需要發布新版本的客戶端，對于麥序調整功能而言，常見的實現方式是為每一種調整方法分配一項單獨的命令號，作為預設指令固化在客戶端。

從上述實現方式來看，上麥時間和麥序控制功能都和客戶端版本強關聯，一旦客戶端版本發布，該版本的上麥時間和能夠支持的的管理員調整麥序的功能就已經確定了，只有替換更新的客戶端版本才能體驗到更新的功能。這將導致了在為麥序模式添加新的功能體驗，例如麥序時間延長、新的麥序位置變化規則時，只有對客戶端更新才能獲得相應的體驗，并且舊的客戶端會出現功能異常的現象。因此需要提出一種在服務器端實現麥序控制的架構，以滿足不對客戶端進行更新的情況下也能在麥序模式下體驗新的功能設計的要求。

為解決這一問題，現有技術中已經存在部分實現方式，其對上麥時間的控制完全由服務器實現，其中，服務器通常會下發一個上麥時長給客戶端，而客戶端在接收到這一上麥時長后便開始計時，從而使得客戶端不用更新版本也可以體驗到新的上麥時間的設置。然而，在這一方案中，由于服務器到不同的客戶端的信息傳遞所需的時長不一樣，導致客戶端的實際的發言時長往往會與服務器通知的上麥時長存在偏差。

例如在如圖1所示的第一語音會話環境中，客戶端102、104、106、108和110為該語音會話的多個成員，服務器100用于對這些成員進行控制，其中，客戶端102、104和106與服務器之間所需的信息傳遞時長為0.8s，而客戶端108和110與服務器之間所需的信息傳遞時長為2.8s。在這一場景下，雖然服務器通知給客戶端102和108的上麥時長是相同的，然而由于客戶端102和108接收到通知的時間有先后，并且服務器在發出通知時便開始對客戶端的發言時間進行計時，因此，客戶端102和108的實際的發言時間將存在2s的偏差，同時也將導致客戶端顯示的發言時間尚未結束前發言即被終止的情況，從而既難以準確地對參與語音會話的成員的下麥時間進行控制，又影響了用戶的體驗。

針對上述的問題，目前尚未提出有效的解決方案。

發明內容