現在大部分遊戲的交易，只允許兩人交易，邏輯如下(假定A和B交易)：
拒絕交易情況：
A(請求和B交易)------>服務器(轉發A的請求至B)------->B(是否接受A的請求交易)
B(拒絕A的請求)------>服務器(轉發B的回答至A)-------->A
同意交易情況：
1) A(請求和B交易)------>服務器(轉發A的請求至B)------->B(是否接受A的請求交易)
2) B(接受A的請求)------>服務器
3) 服務器(通知A，B接受交易，開始交易)---->A
4) 服務器(通知B，開始交易)------------------>B
5) A(添加交易的物品或者金錢)---->服務器(告訴B，A的交易物品或者金錢)------->B
6) B(添加交易的物品或者金錢)---->服務器(告訴A，B的交易物品或者金錢)------->A
7) A(確定交易，A不能增加或者刪除準備交易的東西)-------->服務器
8) 可以重複第6步操作
9) B(確定交易，B不能增加或者刪除準備交易的東西)-------->服務器
10) 服務器(A交易的東西給B，B交易的東西給A[寫入數據庫]，交易成功消息發送至A和B)---->A/B
對於同意交易的情況，只要A確定交易，B確定交易，就算交易成功，但是如果A確定了交易，這時候B刪除了剛纔準備給A的交易東西，然後確定交易，那豈不是A吃虧了？看來這種方法有問題啊！可以有如下兩種辦法解決：
第一種：
交易的時候，只能添加物品或者金錢，添加了東西不能刪除，即第5步和第6步操作中只能增添不能刪除，這樣就確保了交易正確性。
優點：對於玩家來說，操作簡單，更容易理解。對於開發人員：處理邏輯簡單。
缺點：有可能引起玩家誤操作(如：A添加完交易的東西，沒等B添加交易的東西，就確定交易)
第二種：類似於“三次握手”，即上述第9步之後，再給A一個反饋確認，如果A再次確定交易，則進行上述第10步操作。
優點：解決了第一種情況的誤操作。
缺點：對於玩家來說，操作複雜。對於開發人員：處理邏輯複雜。
對於遊戲中的擺攤，只是上述交易的簡化版本，即上述的2)，6)，8)，9)這幾個步驟執行默認操作。
目前，遊戲中還沒有多人交易，即一個物品多個人競拍或者一個人同時與多個人交易。不過個人認爲，競拍以後可能會出現，但是一個人同時與多個人交易應該沒有必要，因爲這種交易引起玩家操作感不好，且程序處理
複雜度高了很多。
