有个delphi上位机软件需要外发，深圳有兴趣的朋友看看

windy__xp · 发表于 2009-12-1 20:31:11

由于一些原因，客户要求上位机软件必须用Delphi写，一来我们开发任务重，没工程师来写这个软件，二来我们目前基本上不用Delphi，也没有精通Delphi的工程师，所以决定这个上位机软件外包。为了方便交流，所以必须是深圳的，南山这边的朋友最好。大概要求如下，价钱方面私下沟通。

功能要求：
1. 软件作为服务端以TCP的方式与远程GPRS通信，远程GPRS上电后，可以连接到服务端，我们提供GPRS心跳包格式以及数据协议；
2. SQL数据库的管理以及操作，我们提供SQL数据库，具体功能私下沟通。

技能要求：
1. 精通delphi7，软件用Delphi7开发，不使用动态链接库以及第三方控件，代码风格良好，关键代码必须有中文注释；
2. 精通SQL数据库；

目前正在整理数据协议和功能需求方面的资料，深圳有兴趣的朋友，请先发个人相关项目经验以及合作意向到我邮箱：larry__zh@163.com，我们私下沟通具体功能需要，以及价钱方面的问题。时间比较紧张，希望这个星期内能找到合适的朋友合作。

windy__xp · 发表于 2009-12-1 20:44:07

不定时的顶一下，请浏览过的朋友也帮忙顶一下，谢谢。

lysoft · 发表于 2009-12-1 20:54:55

我已经开发有成熟系统.TCP连接管理服务器,NT Service线程池COM+分布式3层架构,支持C/S或B/S方式的展示方式,每server最大支持5000个连接.其中服务系统为Delphi2010开发,B/S以及中间件为C#开发,DB为MSSQL2005/2008

这个本来就是我的DTU配套的系统,呵呵
不过要提供整套系统源码的话价格就比较贵了(6位数)^_^

PS,服务端要写的好,真的要话不少功夫的,偶这个系统已经已经在多个监控系统中运行3年了,最初是Delphi2007弄的
如有需要合作,可以私下谈

windy__xp · 发表于 2009-12-1 21:21:32

呵呵，楼上的，我们要求没这么复杂。基本框架搭好后，我们后期自己还需要完善，六位数有点太高，^_^

谢谢

windy__xp · 发表于 2009-12-1 22:33:06

睡觉之前，顶一下。

lysoft · 发表于 2009-12-1 22:37:01

客气啦~要源码是贵的
只要架构,然后自行二次开发就很便宜,1~2K以内就成
如委托我们二次开发也成,可提供这部分源码

zc3909 · 发表于 2009-12-2 01:28:13

帮顶吧

windy__xp · 发表于 2009-12-2 08:53:38

windy__xp · 发表于 2009-12-2 12:23:38

aleyn · 发表于 2009-12-2 13:30:57

达到你的技术要求，但达不到你的地点要求。^_^

windy__xp · 发表于 2009-12-2 19:19:20

跟客户沟通了，说是TCP、UDP都需要，继续整理资料中，目前测试DTU还有些问题，希望这个星期能搞完。

windy__xp · 发表于 2009-12-3 21:45:01

这两天有点急事需要处理，需求文档还没写完，可能要搞到下个星期去了。

Appcat · 发表于 2009-12-3 21:54:22

借问【2楼】 lysoft ，“每server最大支持5000个连接”这5000个连接每个连接是一个线程吗？有没有测试过1000个连接同时活跃时，CPU占用量，内存占用量，线程内部处理时间，线程上下文切换时间，线程内部处理与上下文切换所用CPU时间的比例？

Appcat · 发表于 2009-12-3 21:59:02

楼主这个东西很简单，但是如果加上UDP的支持，恐怕开价要翻番了，UDP不是那么好玩的，如果需要自己做差错控制，远端还是一个gprs设备，这个看用户对协议的要求了，搞不好水很深，要淹死人的。

lysoft · 发表于 2009-12-3 22:01:10

这5000个连接每个连接是一个线程,但IO队列化
同时测试过2000个连接,没有问题,当然CPU占用几乎100%
因为采用线程池技术,对Database的操作是队列化的,IO访问被限制为几个并发,所以,全部请求数据时有一定延迟,但系统仍能正常反应

一般PC机做1000个连接都毫无问题,而目前的Server很多都是2~4个4核心CPU的,5000个并发也不算超大的

lysoft · 发表于 2009-12-3 22:05:22

UDP+连接保障=TCP
所以UDP很麻烦,而且需要下位机的协议保证,除非数据丢失没所谓

偶的一个系统在电力监控系统中使用,为UDP,但其协议自身就要有超时,重发和校验机制,比较的麻烦,所以即便UDP仍能保证OK,

windy__xp · 发表于 2009-12-3 22:16:17

目前我们的需求是，除去心跳包以及紧急事件的上行数据，其他通信过程都是由服务端发起，所以能处理好多少个DTU的心跳包，基本就能处理多少个连接。因为是移动光纤到局，GPRS专用SIM卡，通信相当于内部局域网，所以准备把UDP模式作为一个可选项，界面预留设置即可，如果需要我们自行扩展，目前主要还是使用TCP通信。

Appcat · 发表于 2009-12-3 22:30:55

“UDP+连接保障=TCP ”正解！所以客户要求使用UDP还要保证数据传输正确，纯粹是脱裤子放屁。也许客户就觉得TCP包打包开销比较大，UDP通信能节省流量费，实际用下来流量费估计要让他们吐血。跨越广域网的UDP通信，不是那么好玩的，为确保正确，牺牲的是效率，因为UDP在网络任何一个环节中，都可以不对其负责任的。UDP通信一般都是在局域网中，做一些特殊应用，比如原来我做过一个HIS系统，使用UDP的广播来进行全网时间同步，效率高，速度快，网络开销小，不用进行校验和重发。

说实话，基于.NET的高并发TCP连接没有做过，但是感觉微软在.NET 2.0中对于这个进行了优化，将TCP SOCKET也作为一个IO操作进行序列化了，使用类似的线程池的做法，或者说类似于重叠IO的模式，线程池中的线程数是严格限制的，这样虽然SOCKET要排队，但是线程池中的线程能最大程度运行数据处理逻辑，而不是浪费时间在线程上下文切换中，总体效果自然是好与纯粹的多线程处理。这样的处理方式还有个好处，现在的CPU都是多核超线程的，可以根据CPU内核数和CPU数进行分配线程，这样就不需要线程切换，特别在CPU数增加的时候，性能的提升是与CPU数呈线性关系，这在传统的对称式多处理系统中是不可思议的。

我们原来测试过纯粹的多线程并发连接，3G至强CPU的服务器，一般到600个并发线程就OVER了，即使没有OVER也速度极慢，反应迟钝，基本干不了啥工作了，后来改用WINSOCK2.0的完成端口模型来测试，仅仅开了两个线程，最终跑到1200个并发连接，再往上测试的时候，桌面百兆交换机over掉了，所以这个潜力应该是更大的。

windy__xp · 发表于 2009-12-7 13:59:52

继续up

shutup · 发表于 2009-12-7 16:26:41

17楼是正解，按照之前跟中国游戏中心的总工聊过，纯粹线程的话，一个服务器基本上是600个连接。这个数据是个经验值，是在几十万用户的使用中得出的。线程和线程之间的切换也是要花很多时间的。

基本上用完成端口的模型来做，或者Fiber，效率是要高很多。

关于UDP的的使用，主要是几个优点，
第一.如果协议本身比较简单，考虑了连接保障的冗余度的话，开销会比较小。
第二.对于防火墙的穿透能力较好。。。

windy__xp · 发表于 2009-12-9 09:13:45

zhiyuan1106 · 发表于 2009-12-9 09:24:36

一般电力行业的GPRS前置机连接数如果太多（一般会上万）会用分级前置，底层的前置机负责和GPRS通信，上层的前置机则负责底层前置机和主站之间的通信。链路的维护由底层前置机和GPRS下位机共同完成，当然主要是下位机维护，上位机只负责回复心跳帧和登陆帧。

windy__xp · 发表于 2009-12-14 12:47:07

已签合同，结帖，谢谢各位的支持。

windy__xp · 发表于 2010-1-11 15:01:33

目前合作的朋友发短信说项目无法完成，具体原因不详，目前手机无法联系，但是项目时间紧迫，Delphi 高手们帮一下忙，有兴趣直接电话联系 13640906426。

有个delphi上位机软件需要外发，深圳有兴趣的朋友看看

阿莫论坛20周年了！感谢大家的支持与爱护！！

浏览过的版块