超市前台销售传到后台服务器（文本格式）通过SOCKET通讯，有几个问题，请到里面，多谢(200分)

  • 主题发起人 主题发起人 wangjb
  • 开始时间 开始时间
W

wangjb

Unregistered / Unconfirmed
GUEST, unregistred user!
1。一台服务器2000server,最多接60-100用户，使用非阻塞，有没有问题
2。我现在使用多文件合并传到后台服务器，记录型（文件名1+文件大小1）+文本（文件内容1）+
记录型（文件名2+文件大小2）+文本（文件内容2）+。。。，在服务器段读取文件名，文件大小
时，文件名为乱码，文件大小也与实际不同，为什么？
3。使用SOCKET传输3-4MB文件时，需要20多分钟，为什么？
 
//我现在使用多文件合并传到后台服务器
直接操作数据库不行么？
//使用SOCKET传输3-4MB文件时，需要20多分钟，为什么？
用个WINDOWS的直接COPY也不会这么慢？
我的想法：
直接操作数据库吧。
 
我开发过Pos前台及后台程序，并且实施过几家大中型规模的超市。

1. 经实践，一台 compay 数据服务器联接30左右POS机没有问题。（通常中型超市POS机不会超过30台）
2. 在前后台数据传输时最好不要采用合并方式，单机单传单丰为最佳方式。有利于数据的后台导入。
3. 在前台销售数据庞大的情况下，数据传输可以会慢一些。
通常Pos机在全天的全额销售情况下数据也不过几百K而已，出我的经验，传输1MB的文件大约5-7秒左右
 
阿梁，能说说你的SOCKET编程思路吗？
 
建议直接对数据库操作。
因为数据量并不是很大。
 
直接对数据库操作有弊端，你是怎样用SOCKET的？
 
to lili365:
将数据库的表转换成文本后，建立连接，SERVER端发送一个START字符，CLIENT端发送2046
个字节，SERVER端接收后，再发送START字符，依次类推，直到一个文件发送完毕。再发送
下一个文件。
TO donggang_cn1:
由于收款机有50-60台，用数据库易造成死锁等问题。
 
直接对数据库操作肯定是不行的，

POS程序和其它程序不同，前台数据和后台数据绝对不允许是实时的。

就我看国内外的大型POS前后台，用socket的也不是主流。




 
to 阿梁
那你说是不是用FTP比较保险。
 
》POS程序和其它程序不同，前台数据和后台数据绝对不允许是实时的。
不懂是什么意思，我想POS程序不能直联数据库的原因是它可以脱机交易。没做过POS程序
我在类似系统中采用SOCKET通讯，速度完全可以满足，基本上在10M网上可以达到3、4M吧。
 
用socket进行数据传输做的比较好有前台销售有打天下等，但它采用数据实时传送，大型超市不推荐使用。

如果你感觉socket实现困难的话，可以直接读服务器上的文本文件，这是取简单的办法。
 
to 阿梁
使用FTP上传文件有什么缺点？
 
我没有用过FTP方式，你的问题解决了吗？
 
to 阿梁
我怀疑可能给定义的握手方式有关系，我是先传文件大小，然后服务器发送一个字符表示
接到，客户端接到字符后发送数据，服务器接到后，再发送确认字符，依此类推，直到数据
发送完毕。

”可以直接读服务器上的文本文件“，这是什么意思，我不太懂.
 
接受答案了.
 
我觉得直接连数据库没问题，我现在的单位就有40台Pos机加50台后台业务查询工作站呢！

 
您必须登录或注册才可回复。

Similar threads

X
使用kbmmw 的REST 服务实现上传大文件 - xalion
回复
0
查看
1K
xalion
X
X
kbmmw 的HTTPSmartService 上传文件到服务器端 - xalion
回复
0
查看
948
xalion
X
X
kbmmw中向服务器端传递对象的一种简单方式 - xalion
回复
0
查看
848
xalion
X
S
[原]Delphi2010中DataSnap高级技术(6)—加强服务程序对访问者的控制能力
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
[原]Delphi2010中DataSnap高级技术(6)—加强服务程序对访问者的控制能力
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
后退
顶部