小弟研究了一下，现在有一个初步的构想，请各位批判一番。
服务端方面：一个socket用来接收客户端的socket请求，根据约定的数据头来确定是登陆服务器的功能还是功能服务器的功能。然后再将这个请求发送给登录服务器或者功能服务器。准备用boost库，同步多线程的方法来写。
客户端方面：我是这么想的，我要写个DLL给写C#的人来用。他通过我的接口可以跟数据库进行交互，发送数据给服务端可以手动发送write来实现，服务端可以用个死循环来不断接收。但是客户端从服务端接受返回来的数据小弟就有些想不明白了。总不能在客户端也写个死循环来不断接收服务端返回来的数据吧？
小弟也尝试过用回调的方法，可是还是不甚了解。身边又没有可以请教的人。哈哈，还请大神不吝赐教一二。
2 个解决方案
#1
我已及其七颗龙珠召唤大神
#2
有两种写法：
1.web api，restful风格，不同的功能，对应不同的URL，客户端通过对不同URL的调用，直接实现交互。缺点是不能简单地实现服务器向客户端的推送，如果没有这种服务器到客户端的推送需求的话，强烈推荐这种（即使有，也可以通过轮询来曲线救国，或者改用长连接）
2.socket，好处是可以直接建立一个长连接，数据双向发送都很简单，麻烦的地方是需要处理数据传输的细节，需要对数据的结构进行解析，开发难度更高一些。SOCKET的逻辑是，服务端用一个死循环来执行监听，一旦遇到连接请求，就另开一个单独的线程去接收连接，并且注册数据接收的事件；数据接收也是一样，有消息来了，另开一个单独线程执行接收动作
你可以参考一下这个，每一行代码都有详细的解释
http://www.cnblogs.com/sunev/archive/2012/08/07/2625688.html
1.web api，restful风格，不同的功能，对应不同的URL，客户端通过对不同URL的调用，直接实现交互。缺点是不能简单地实现服务器向客户端的推送，如果没有这种服务器到客户端的推送需求的话，强烈推荐这种（即使有，也可以通过轮询来曲线救国，或者改用长连接）
2.socket，好处是可以直接建立一个长连接，数据双向发送都很简单，麻烦的地方是需要处理数据传输的细节，需要对数据的结构进行解析，开发难度更高一些。SOCKET的逻辑是，服务端用一个死循环来执行监听，一旦遇到连接请求，就另开一个单独的线程去接收连接，并且注册数据接收的事件；数据接收也是一样，有消息来了，另开一个单独线程执行接收动作
你可以参考一下这个，每一行代码都有详细的解释
http://www.cnblogs.com/sunev/archive/2012/08/07/2625688.html
#1
我已及其七颗龙珠召唤大神
#2
有两种写法：
1.web api，restful风格，不同的功能，对应不同的URL，客户端通过对不同URL的调用，直接实现交互。缺点是不能简单地实现服务器向客户端的推送，如果没有这种服务器到客户端的推送需求的话，强烈推荐这种（即使有，也可以通过轮询来曲线救国，或者改用长连接）
2.socket，好处是可以直接建立一个长连接，数据双向发送都很简单，麻烦的地方是需要处理数据传输的细节，需要对数据的结构进行解析，开发难度更高一些。SOCKET的逻辑是，服务端用一个死循环来执行监听，一旦遇到连接请求，就另开一个单独的线程去接收连接，并且注册数据接收的事件；数据接收也是一样，有消息来了，另开一个单独线程执行接收动作
你可以参考一下这个，每一行代码都有详细的解释
http://www.cnblogs.com/sunev/archive/2012/08/07/2625688.html
1.web api，restful风格，不同的功能，对应不同的URL，客户端通过对不同URL的调用，直接实现交互。缺点是不能简单地实现服务器向客户端的推送，如果没有这种服务器到客户端的推送需求的话，强烈推荐这种（即使有，也可以通过轮询来曲线救国，或者改用长连接）
2.socket，好处是可以直接建立一个长连接，数据双向发送都很简单，麻烦的地方是需要处理数据传输的细节，需要对数据的结构进行解析，开发难度更高一些。SOCKET的逻辑是，服务端用一个死循环来执行监听，一旦遇到连接请求，就另开一个单独的线程去接收连接，并且注册数据接收的事件；数据接收也是一样，有消息来了，另开一个单独线程执行接收动作
你可以参考一下这个，每一行代码都有详细的解释
http://www.cnblogs.com/sunev/archive/2012/08/07/2625688.html