现在大部分游戏的交易，只允许两人交易，逻辑如下(假定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)这几个步骤执行默认操作。
目前，游戏中还没有多人交易，即一个物品多个人竞拍或者一个人同时与多个人交易。不过个人认为，竞拍以后可能会出现，但是一个人同时与多个人交易应该没有必要，因为这种交易引起玩家操作感不好，且程序处理
复杂度高了很多。
