关于是否应该使用socket来发送数据的问题

[战箫]

我现在要写的程序是这样的
数据库使用的是Sql server2000,在租用的一台VPS方式的服务器上，有固定IP，客户端需要把数据写入数据库或获取相关数据显示在客户端等
我现在不知道哪个方案好
1.让客户端直接连接数据库
2.另写一个服务器端程序，让客户端通过socket连接服务器端程序，读写数据库由服务端实现

注：客户端需要传递的数据量比较大，多的情况下每次可能需要传递500万-1000万字节，大概会有2000左右个客户端，每个客户端使用频率大概每天10次以内
方案一应该容易实现，方案二要操作socket，可能复杂些吧？

[贝隆]

使用方案一，就你说的，简单

[threenewbee]

可以使用wcf。作为服务器端agent。

[战箫]

[Quote=引用 1 楼 veron_04 的回复:]

使用方案一，就你说的，简单
[/Quote]

方案一，对我来说实现没问题，写过很多这种程序，只是这次不一样的地方是客户端比较多，一次传递的数据量也比较大，而且是走广域网，不知道同时有几百个客户端同时发数据的话会不会有什么问题？

方案二，主要是我经验比较少，大数据量使用socket传递的话，是不是应该分多次传递，多次的传递如何接收组装，没啥经验，心里没底

[咸清]

方案一，对我来说实现没问题，写过很多这种程序，只是这次不一样的地方是客户端比较多，一次传递的数据量也比较大，而且是走广域网，不知道同时有几百个客户端同时发数据的话会不会有什么问题？

Oracle默认上限是65535个连接，数据库系统本身占用一部分端口以及代码不规范，一个程序占用多个连接的情况，3000台电脑同时操作数据库就难以顶住了。
SQL Server 2000参考如下：
设置用户连接数，键入或选择一个值（介于 0 到 32767 之间），以设置允许与 SQL Server 实例同时连接的最大用户数量。
设置连接数方法：
在企业管理器中打开Sql Server属性（配置） ，选择“连接”页面，在其中设置连接数

我认为数据量大的时候，数据库压力还是很大的。如果是我，就用UDP协议扩展一下用第二种方案。

[dbcontrols]

"让客户端通过socket连接服务器端程序，读写数据库由服务端实现"
客户端需要传递的数据量就少了么？我看方案2是多此一举，还是干那些活，如果让服务器多干活的话就在服务器端写存储过程好了。

[战箫]

[Quote=引用 5 楼 dbcontrols 的回复:]

"让客户端通过socket连接服务器端程序，读写数据库由服务端实现"
客户端需要传递的数据量就少了么？我看方案2是多此一举，还是干那些活，如果让服务器多干活的话就在服务器端写存储过程好了。
[/Quote]

可能我说的不明白，主要是数据库的连接少了，当然数据量还是那么多，都是服务器干活，只是数据库不需要对几百个连接对话，只跟一个服务端程序连接就可以了。

就是不知道方案一所有客户端都去连接数据库，这里存不存在什么隐患

[homer3382]

[Quote=引用 10 楼 tiger_zhao 的回复:]
同时连接的客户端太多，而且都是往相同的表写数据，发生多用户冲突的概率就很大了。
还是先上传数据文件到服务端，然后服务端由一个专门的程序读取文件写入数据库。
[/Quote]
专门的程序读取文件写入数据库 这样不存在多用户冲突？难道一次只能处理一个用户上传的数据，让其它的用户数据等着？

[现在还是人类]

其实两种方案在压力比较大或环境比较复杂的环境中都会有一定的问题或麻烦的地方。
就通过系统的数据对象直接连接数据来说吧，在面向Internet的网络来说，也有一定
的问题的，比如在 SQL 2000 的数据库，某条数据有 30 MB，然后7个用户同时访问
这条数据，不说 Internet 网络，就是局域网都有可能有一两个点挂掉。如果是数据
量小一点的记录，能承受多少个点同时访问同一条数据这很难做到比较全面的测试。
如果客户用 3G 或 GPRS 方式上网，那要处理比较大量的数据读写也是很困难的事。
总的来说，不出问题就好，如果出问题，这种第三方问题是很难自己解决的。

对于自己用Winsock写三层结构的服务程序与客户端来分发任务处理数据库的做法，
扩展性可以很强，可以满足很多自己的需求，但是相对的也会带来很多问题。
1、程序的稳定性
2、系统资源和程序性能的控制
3、数据传输的过程优化
但因为是自己做过程，出了什么问题，自己可以很方便跟中和解决问题，这点要比处理
第三方问题要好一点。

就程序的稳定性来说，要做到“稳定”，需要花很大的精力和时间，而 VB 本身自带的
WinSock 控件在 Internet 中表现本来就不是很稳定，不说 2000 个各地的 Internet
用户连接，就 200 个都可能会发现很多问题，如果自己用 API 写过程，在资源控制上
也会有一堆的问题。但这些不是不能解决的问题，只是需要时间和经验。

从系统资源和程序性能控制来看，VB这一块比较若，相对来说，VB 要做这种服务程序不是
很适合，如果换开发工具，当然可以解决这个问题，但开发难度也会随之增加。

从数据传输的过程优化来看，如果这点不做，对于一些网络环境不好或需要传输稍微大点数据
的开发需求来说，肯定会是个疙瘩，但要解决这个问题又需要了解并掌握一些比较高效的压缩
解压技术。比如使用 PPMD、LZMA 等技术做内存压缩，然后通过握手传输压缩数据，这样可以
提高网络传输数据的效率，不过这种过程要用 VB 来写效果不会太理想。

如果要用这种方案，还不如直接用一些 WEB 服务程序，用服务器脚本来实现传输和数据读写
过程。因为网络服务程序的稳定性就不用考虑的，直接交给IIS或阿帕奇等程序去处理，只要
直接写个 COM 组件或接口给脚本调用数据处理过程，客户端无论是使用现成的 HTTP 对象或
自己用写 Sock 客户端，都比较容易处理，稳定性和性能也有一定的保障，开发难度相对要
低很多。

[捧剑者]

能用b/s最好。

[chinaboyzyq]

方案二可以操作winsock,不算复杂，但要用TCP同时连接2000客户端，可能不太现实，可考虑UDP协议。

[战箫]

[Quote=引用 7 楼 chinaboyzyq 的回复:]

方案二可以操作winsock,不算复杂，但要用TCP同时连接2000客户端，可能不太现实，可考虑UDP协议。
[/Quote]

2000个客户端是所有的，但不会同时连接，现在对winsock发数据的封包拆包不熟悉

方案一的话所有客户端都使用同一个数据库的账号去直接连接有没有问题呢？

[soarsoar77]

还是第二种方案安全点，隐患比较少

[Tiger_Zhao]

同时连接的客户端太多，而且都是往相同的表写数据，发生多用户冲突的概率就很大了。
还是先上传数据文件到服务端，然后服务端由一个专门的程序读取文件写入数据库。

[king06]

要用winsock发数据需要自己制定一下协议.搞了几天,发现不太理想,主要就是等待回应的过程处理麻烦一点.
不过我没有用winsock,后来用web service弄了个.

[咸清]

[Quote=引用 13 楼 supermanking 的回复:]
其实两种方案在压力比较大或环境比较复杂的环境中都会有一定的问题或麻烦的地方。
就通过系统的数据对象直接连接数据来说吧，在面向Internet的网络来说，也有一定
的问题的，比如在 SQL 2000 的数据库，某条数据有 30 MB，然后7个用户同时访问
这条数据，不说 Internet 网络，就是局域网都有可能有一两个点挂掉。如果是数据
量小一点的记录，能承受多少个点同时访问同一条数据这很……
[/Quote]
不知道.Net有没有解决方法~
或者此类问题的框架之类的~

[现在还是人类]

[Quote=引用 15 楼 ybh37 的回复:]
不知道.Net有没有解决方法~
或者此类问题的框架之类的~
[/Quote]
.net 我不是很清楚，不过以前初步的碰过一两下，没发现在这一块有什么很突出的表现。
不过这一块的三层结构我到做过，服务器端用VC6写NT服务程序和管理用的应用程序，客户
端是用VB写的一个模拟ADO的类，本来想做一个OLEDB提供者程序直接提供给ADO对象访问，
但因为没有完全吃透和时间问题，所以用VB写类的方法实现了一个，数据压缩部分是用VC6
写的一个PPMD压缩解压接口来处理，总的来说，效果还不错。当时是因为客户都在一些偏远
的地方，网络环境不太好，然后需要将客户的资料同步到Internet服务器，为了让这些客户
能够上网，所以只能用3G或GPRS上网，但流量和速度还有大量的数据就会成为很大的问题，
所以弄了这个东西。PPMD的压缩比很高，通常都是10:1的压缩比，有时候还会更高，这段
时间在弄LZMA，据说比PPMD压缩比还高。