在游戏互交时,敢考虑使用HttpClient协议来做通讯么?
我见好多游戏.例如麻将,斗地主,捕鱼之类的,棋牌类吧.都使用了httpClient协议来做.
也见很多游戏直接使用socket.
在这里.个人不是很理解,由于是从php过来的.对C++ java 都不是很熟悉,想使用php来操作交互.
如果使用php这种网页型的来做.和直接c++ java写的服务端之间有什么差别?影响是否非常的大.?
补充:看了下,如果想游戏被广播.就得一定考虑socket 服务端与客户端了.
如果使用HttpClient 就无法被广播了?
============================
9-19-10:00
补充: 鉴于准备些个麻将类的棋牌游戏.最好的选择是哪种协议?
服务端应该使用java 或者 c++了.
问1:为了节省服务器资源,全部使用短连接.? 这可行?
问2:要对客服端广播,也需要在客户端里做个类似服务端的来接收信息?
php做短连接的游戏还是可以的，但想长连就不行了，http是无状态的网络连接，请求一次后就断开了
不重新请求是没办法知道服务器端的变化。除非做心跳请求，不过哪样会拖慢你的服务器
所以想要接到广播这样的逻辑，就一定要使用长连，当然，也可以用长连加短连配合着用
这样你就可以在php写大量的逻辑，只有需要广播的时候在用C++或是java
主要是看服务器承载。
对于一些棋牌类游戏， 大厅使用HTTP是很OK的。
但如果即时玩法（比如实际的牌局逻辑）， 交互过多，且需要后端广播太频繁的，建议使用SOCKET。
可以考虑 大厅HTTP ，房间SOCKET的方式。
我目前就是这样做的
不好意思.新人呢.
对于广播二字.暂时未算很了解.
理解的过程是…客户端提交数据时,同时记录这个客服端的ip和端口.
进行广播时,就把这些ip同时广播出去?
一个棋牌游戏,有必要用到长连接吗?毕竟服务器资源有限的情况下.
个人理解，棋牌游戏中，每个玩家（每个客户端）都要随时显示场上最新的动态，因此实际上是需要不停的从服务器获取信息的，如果是这样的话，socket应该更好。
如果是不停的获取信息,用麻将为例.
ABCD 4个用户
A在摸牌时,在想怎么打那个牌,从通知A用户开始摸牌时,无论打出没打出,各种问题存在,这里不用理解,我们来个假设时间长度为30秒时, BCD 3个用户,每秒短连接一次.服务器压力也很大.
这样的话.还不如使用socket的长连接.可 SOCKET的长连接,貌似有连接上限限制 (没具体了解,不知道是真假) ?
我见有些人使用. 双端,也就是服务端和客户端.都使用UDP.收到什么参数,就执行什么参数.可以这样来想如何开发2端的连接问题?
假设客户端,要发送 个参数 1 到服务端.在3秒内,服务端没返回 1给客户端.客服端又在发送1次,发3次后,判断自己的网络是否有问题.
假设服务端, 要发送个参数 2 到客户端,3秒内,没收到该客户端A的返回 2.则在发送,发送3次.3次后还没收到,则通知BCD 3个用户客户端知道,用户A 88了,断线了.,
如果是不停的获取信息,用麻将为例.
ABCD 4个用户
A在摸牌时,在想怎么打那个牌,从通知A用户开始摸牌时,无论打出没打出,各种问题存在,这里不用理解,我们来个假设时间长度为30秒时, BCD 3个用户,每秒短连接一次.服务器压力也很大.
这样的话.还不如使用socket的长连接.可 SOCKET的长连接,貌似有连接上限限制 (没具体了解,不知道是真假) ?
我见有些人使用. 双端,也就是服务端和客户端.都使用UDP.收到什么参数,就执行什么参数.可以这样来想如何开发2端的连接问题?
假设客户端,要发送 个参数 1 到服务端.在3秒内,服务端没返回 1给客户端.客服端又在发送1次,发3次后,判断自己的网络是否有问题.
假设服务端, 要发送个参数 2 到客户端,3秒内,没收到该客户端A的返回 2.则在发送,发送3次.3次后还没收到,则通知BCD 3个用户客户端知道,用户A 88了,断线了.,