关于Dtu的TCP传输文件的几个问题

eliachen · 发表于 2012-5-25 20:24:02

tcp传文件，大家如何定义文件传输，是先发送文件信息，接着直接传送文件的字节流吗？怎么判断结尾？如何纠错？

我现在做的思路，是对文件二次封包，把发出取得每个包都自己再次定义序号，定义数据长度，然后上位机再次处理，重新提取？

这样做的思路怎样》大家对于这种传文件的思路是怎样的？

还有就是最近有个纠结的问题，我在上位机接受数据的时候，发现一个问题，在接受数据字节流的时候，对于TCP的封包，如果下位机发送1k字节，上位机我的缓冲区设为1k字节，很有可能是不是没办法收到1k字节？

对于TCP这种字节流的编码，他的消息是没有边界的，在处理设备传上来的数据，怎么判别？（就是对于设备发上来的信息，有的可能是控制信息，有的是数据信息），大家对于tcp传送的数据，怎么判别消息的边界，怎么合理的收发？

希望大家讲讲思路，还有就是对于上位机编程的看法！！！

谢谢了！！！！！！

eliachen · 发表于 2012-5-25 20:25:59

还有就是最近有个纠结的问题，我在上位机接受数据的时候，发现一个问题，在接受数据字节流的时候，对于TCP的封包，如果下位机发送1k字节，上位机我的缓冲区设为1k字节，很有可能是不是没办法收到1k字节？

这个问题就说，有可能先收到300字节，然后再收到700字节，而不是一次收到1k字节！

eliachen · 发表于 2012-5-26 16:59:15

自己顶下吧，都沉了！

eliachen · 发表于 2012-5-26 17:00:55

自己顶下吧，都沉了！

hubaixdl123 · 发表于 2012-6-1 08:22:51

帮顶，我也想知道这样的问题。

lengshuicha · 发表于 2012-6-1 08:58:15

友情帮顶，这里有做DTU的成功者，希望他们出来解答。

gaoshou5432 · 发表于 2012-6-1 17:33:18

1 是你自己的主控MCU写的TCP/IP协议还是你用的模块内部的TCP/IP
2 如果是前者这个你是可以控制的.如果是后者每个模块厂家为了自己TCP/IP的稳定性(排除网络的丢包)会有所不同.像W公司的模块就默认情况下一个TCP/IP包是536 当然最大可以改为1460 但是默认时是先发16个字节然后再发其它的.这个也是可以配置的.
3 所以如果大家在使用各厂家的GPRS模块的内部协议时,要特别注意,最好能找到长期的技术支持.如果你只是学习或是研究倒无所谓.但是如果做产品.持续的技术支持还是很重要的.

gaoshou5432 · 发表于 2012-6-1 17:34:32

4 关于你的要求.为什么不直接用FTP.这样可能会比较简单.

eliachen · 发表于 2012-6-2 12:44:04

gaoshou5432 发表于 2012-6-1 17:34
4 关于你的要求.为什么不直接用FTP.这样可能会比较简单.

恩，我最近也在看，怎么搞？

eliachen · 发表于 2012-6-2 12:53:24

gaoshou5432 发表于 2012-6-1 17:33
1 是你自己的主控MCU写的TCP/IP协议还是你用的模块内部的TCP/IP
2 如果是前者这个你是可以控制的.如果 ...

我用的是sim900B的模块，内部有tcp和udp的协议！

gaoshou5432 · 发表于 2012-6-4 17:36:38

看一下手册,有没有FTP GTM900太老了,可能没有.有些模块是有的.FTP MMS.. 和TCP操作都一样.都是透传数据

gaoshou5432 · 发表于 2012-6-4 17:43:32

附图FTP 文件上传.其实用TCP就可以了. 只是和上位机之间做好检测就好了.第一包见意先把文件长度给传上去.

Appcat · 发表于 2012-6-4 17:51:14

既然楼主上升到了DTU透明传输这个层次了，就不要再纠结DTU内部是如何实现的了，你把DTU想象成一根串口线，那头发文件，这头接收端要怎样才能正确的收到文件。楼主位的思路是对的，将文件二次分包，加上顺序号和数据长度校验，数据错误校验就不要加了，TCP已经替你做好了这个工作了。
严格按照分层网络模型来考虑，TCP的DTU替你解决了下三层的问题，你的工作就是在分层模型的网络层以上去实现一个针对业务应用的应用层协议。上面所说的二次分包什么的都是这个应用层协议的组成部分。在网络层上，就可以吧往下的部分当做一个串口线，这也是DTU所谓透传的意义。
至于为什么下面发1K字节，上面会分别收到300字节和700字节，这个完全是底层的TCPIP封包边界造成的，对于上层应用协议来说，不能依赖于对下层的假设，而是要自己进行拼包，识别包边界。如何识别包边界，在你对文件进行二次封包的时候就可以自己加上协议。
看了楼主在10楼的发言，楼主一方面需要考虑TCP层如何运作，还要考虑上层软件如何运作，显然是混到一起考虑了。这样会很累的。先解决好一个层面的问题，再考虑另外一个层面的问题。

eliachen · 发表于 2012-6-4 23:34:13

Appcat 发表于 2012-6-4 17:51
既然楼主上升到了DTU透明传输这个层次了，就不要再纠结DTU内部是如何实现的了，你把DTU想象成一根串口线， ...

恩，好的。
我就想问下，现在的模块就是一般都是class8的，只有一个上行信道，有没有class10的，就是上行信道有两个的（我知道西门子的mc55是class10的，还有没有别家的也是class10的或者是class12的）？

hubaixdl123 · 发表于 2012-6-8 09:55:07

本帖最后由 hubaixdl123 于 2012-6-8 10:20 编辑

Appcat 发表于 2012-6-4 17:51
既然楼主上升到了DTU透明传输这个层次了，就不要再纠结DTU内部是如何实现的了，你把DTU想象成一根串口线， ...

利用Ethereal抓到的TCP数据包
appcat:你好，如图所示，是用Ethereal抓到的GTM发送到电脑的TCP数据包，从图中可以看出，发送到服务器的数据已增加了IP的首部，TCP的首部等数据，最后是要发送的数据“12345AB"。
1.是不是说对于数据的打包我们不用再去作处理了？如果我想每次发送500字节的数据，直接用AT%IPSEND="要发送的内容"发出就可以了吗？
2.如果服务器没有接到某个数据包，单片机要作怎样的处理？还是模块自动处理？
3.如果我想从GTM900B发一个图片到服务器，要了解那些知识？用单片机控制它的流程是什么？

你是这方面的专家，在OURDEV上面发了很多程序，相当一部分的问题都是你回复的，可是现在都无法下载，可以在此再贴一次吗？其它地方很难找到相关内容。谢谢！

eliachen · 发表于 2012-6-8 18:56:29

hubaixdl123 发表于 2012-6-8 09:55
利用Ethereal抓到的TCP数据包
appcat:你好，如图所示，是用Ethereal抓到的GTM发送到电脑的TCP数据包，从 ...

1、你要先了解一下协议，我们用的都是模块内部的协议栈，AT%IPSEND="要发送的内容，之后会回复一个send ok或者别的命令，这个你要用超时捕获，如果用的是透传，要设置好重传的时间和次数。
2、这个要下位机自己处理的，而且两者之间是要有交互的，比如说丢包重传！
3、发图片什么的其实还是byte流，抽象出来其实就是把一堆byte流传送到上位机，而且要完整，自己要有控制！

first_blood · 发表于 2012-6-8 19:34:44

传文件可以用tftp协议，这个很简单的，或者y-modem，可以自定协议，直接用UDP，就没有什么边界问题，也快，TCP负责传输命令，UDP传文件数据，自己做好丢包重传就行了，tftp改改就很好

Appcat · 发表于 2012-6-8 19:39:54

hubaixdl123 发表于 2012-6-8 09:55
利用Ethereal抓到的TCP数据包
appcat:你好，如图所示，是用Ethereal抓到的GTM发送到电脑的TCP数据包，从 ...

其实16楼的回答的很好了。

你用的抓包软件不错，但是对于你只是在TCP层以上工作的话，这么多信息显然是对你造成了困扰。你的IPSEND发送了什么数据，上面一定会收到这个数据，其他的东西，都是TCP层或者以下的信息，你可以不用理会。
如果收不到数据包，你应该自己进行处理，也就是说你的程序和服务器的程序要商定一个格式，这样才能发现数据包丢，才能进行重传，而不是将原样数据扔给模块，这样出了问题你什么都不知道。更进一步的说，TCP是面向连接的协议，如果数据包收不到，一般情况下你不必着急处理这个问题，因为往往是更加严重的问题才导致的：断线。这个问题一般的处理思路就是超时+重连，对于数据就是超时+重传。

eliachen · 发表于 2012-6-9 12:27:39

first_blood 发表于 2012-6-8 19:34
传文件可以用tftp协议，这个很简单的，或者y-modem，可以自定协议，直接用UDP，就没有什么边界问题，也快， ...

tftp这个没大接触啊！能介绍下吗？我现在是用透传

sos0514 · 发表于 2012-6-21 14:20:55

好贴！

Julius20110 · 发表于 2012-11-5 11:02:07

标记一下

关于Dtu的TCP传输文件的几个问题

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

本帖子中包含更多资源

本帖子中包含更多资源

浏览过的版块