c****t
发帖数: 19049 | 1 363 命中D3
四四方方，形似大板砖的导弹车慢慢的开出了山坳，在导弹车的后面是四联装高射机枪
，张小强带着杨可儿与上官巧云站在导弹车的前方，每个人都如临大敌的准备下面的决
战，同时也是张小强第一次与D3的决战。
两只粗长的炮管慢慢降低射界将炮管对准了远处的D3，同时导弹车也在放下车身边角的
千斤顶固定车身，等到一切准备就绪的时候，张小强深吸一口气对着高炮组大声喊道，
“停止行动，停止行动，做备战准备·····”
虽然高射炮的有效射程在3000米，可张小强却不相信自己的高炮组能在一千米的中长距
离能准确命中一个高不过三米的目标，就算那四个管子的四联装都得让丧尸靠近到二百
米的范围之内，用火力网才能干掉，用高射炮他心底实在没底，要是在第一时间没有击
中，反倒可能将D3引过来。
到时候D3近身，14.5毫米高射机枪打不穿它的厚壳，说不定整个车队就杯具了，为此，
张小强就定多做一些准备。
三十个拿着工兵锹的队员在张小强的带领下，小心翼翼的摸到了高炮前方四百米的地方
开始挖掘壕沟，他们挖的很小心，尽量不发出大一点的声音，张小强则举着望远镜观察
着D3的动静，在观察的同时还要时刻的注意风向，只要... 阅读全帖 |
|
r******0
发帖数: 2753 | 2 大王说了，树不行，要是醉鬼开的车太猛，把树撞倒了，还是一样要砸到你家房子。正
确的做法是门口挖个（鱼）塘，或者陷马坑也行，让他一头栽进去。 |
|
k***g
发帖数: 7244 | 3 【 以下文字转载自 ChinaNews 讨论区,原文如下 】
发信人: yaz (柏林低温武警), 信区: ChinaNews
标 题: 河南籍民工在温州为救两孩童英勇献身
发信站: Unknown Space - 未名空间 (Wed Mar 2 18:39:36 2005), 转信
http://www.sina.com.cn 2005年02月28日10:17 郑州晚报
这就是李学生生前的家，中华楼村68号。晚报记者 廖谦/图
近期陆续有很多河南在外的务工人员用生命感动了异乡，他们感人事迹的背后
，是河南形象的亮丽。晚报记者 廖谦/图
李学生一家三口照片。晚报记者 廖谦/图
核心提示：2月20日，在温州打工的河南籍民工李学生，当日下午在行至金(金
华)温( 温州)铁路温州市黄龙段马坑隧道口时，面对呼啸而来的列车，飞身救出一
个穿越铁道的男童，而当他去救另一个遭遇危险的女童时，被飞驰的火车迎面撞飞
，献出自己36岁的生命。事件发生后，在温州引起了巨大的反响，当地传媒和政府
均给予了李学生的行为很高的评价，团温州市委追认他为“温州市见义勇为好青年
”，温州市委号召全市外来务工人员和干 |
|
l**n
发帖数: 7272 | 4 最原始一些MK802帖子已经被删。在这里保存一下。
发信人: weidong (伊拉克学习小组副组长), 信区: PDA
标 题: MK802玩机资源
发信站: BBS 未名空间站 (Mon Jul 9 23:00:58 2012, 美东)
鉴于玩这个的WSN有那么几个, 现在放出几个有用的连接.
https://www.miniand.com/forums
http://rikomagic.co.uk/forum/
有意思的是, 一票人不专心搞安猪ROM, 反正在兴高采烈的刷LINUX. 靠.
我准备明天定个5-6刀的USB RJ45看看能不能从NAS上STREAM 1080P. 升级家里WIFI是太
贵了. 好在装网络的时候ATT送了几个POWERLINE LAN adapter....周末看看吧．
发信人: weidong (伊拉克学习小组副组长), 信区: PDA
标 题: MK802高清流媒体项目近日取得突破性进展
发信站: BBS 未名空间站 (Fri Jul 13 02:38:34 2012, 美东)
最佳设置组合:
1. SYNOLOGY NAS 212j存放媒体... 阅读全帖 |
|
s****c
发帖数: 11300 | 5 写的挺好的 其实像你这样客观的反而没有市场
果黑看不到喷点 果粉想赞吧 又大部分都没用过android 呵呵
又是 |
|
p******9
发帖数: 7130 | 6 三丧起名字真逗
S2 - 傻二
S3 － S13少1
SB - 不解释
下一个估计应该是Samsung Galaxy S 13了。
估计三轮们要欢呼雀跃去排队抢购了。
又是 |
|
i*****o
发帖数: 1714 | 7 害的我几个晚上没睡个好觉！
一直在用linux好久，时不时碰到个小问题，可从来没有到让人气愤的的地步，毕竟
linux好处多多，一点小问题就算了。可这次太让我忍无可忍，不得不上来骂几句。
话说偶在做一个voip的app，用linux做中转。linux上的code很简单，就是每20ms来个
50字节，从一个socket放到另外一个socket，这对偶做了n年网络工程师的人来说，小
菜一叠吧。可用这个app通话质量很差，偶抓破头皮看client的code，也没啥问题。用
sniffer看，原来每个packet间的间隔时大时小，导致很多packet不能按时到达，就过
期作废了。看sender的pattern，非常整齐。那就是linux的问题，偶就开始time自己的
code，同样的非常整齐，没有任何延迟。那是什么原因让linux不马上把偶的data传出
去，而看似毫无规律的乱传？
通过无数个google，bing，终于发现问题的根源。是linux作者在胡乱implement tcp
slow start. Slow start 的spec说tcp session can start with... 阅读全帖 |
|
j*a
发帖数: 14423 | 8 pls do submit a patch. contribute back to community. |
|
l*****n
发帖数: 633 | 9 your voip app runs on tcp? why not udp? |
|
|
i*****o
发帖数: 1714 | 11 我想了很久为什么这个问题只有我碰到，google也没能帮多少忙，大概就是你说的，别
人都用udp。可我同样的code，如果对方不在，就voicemail存下来，不想丢frame。还
有我用http bypass firewall, 只有这样了。
★ 发自iPhone App: ChineseWeb 7.3 |
|
i*****o
发帖数: 1714 | 12 不用patch, config cwnd change就好了。
看到很多报道，所有大网站，google,msn,yahoo, init cwnd都从3改成10之类。
★ 发自iPhone App: ChineseWeb 7.3 |
|
m**k
发帖数: 290 | 13 99% sure it's nothing to do with "wrong implementation" of TCP slow start.
you shouldn't use TCP at the first hand.
you need to know more about how a packet is transfered from a socket buffer
to driver and then to physical card. There are multiple buffers in this
process. |
|
j*a
发帖数: 14423 | 14 patch一下改成default吧，既然你说原作者误读了规范的文档 |
|
|
i*****o
发帖数: 1714 | 16 这个要改可不是几行程序就能解决的。linux现在这方面有很多算法，每个都去测试就
累死了。这也是为甚么我在这个问题上花了很长时间。因为我直觉是tcp 哪个window的
问题，就去把每个算法的每个参数都拿来试，希望瞎猫碰死耗子，结果每个都不行，几
乎崩溃。 |
|
v*****r
发帖数: 1119 | 17 既然问题是packet间隔时大时小, set socket to use tcp_nodelay 试了吗？ |
|
|
z**r
发帖数: 17771 | 19 UDP也不能。但是UDP开销小的多，对delay or jitter敏感的应用，无一例外都是用udp
。导致TCP延迟的因素太多了，这里面水很深很深，楼主说不是sender端，就是linux中
转出问题了，这个假设漏洞太多，基本不成立。
最关键的是，楼主的问题解决了吗？还是做了一番研究就放弃了？
这个tcp window不光和congestion window有关，也和advertised window有关，还有
ACK, retransmission等等。楼主要搞定这个问题了，欢迎给大家详细讲讲，俺发大包子 |
|
h*******t
发帖数: 2679 | 20 你的音频帧难道没有时间戳吗？时间戳当然是在发送端打。接收端存下来以后重新解码
，解码时时间戳就起作用了。
接收端接到数据后再打时间戳的话，鬼都不知道被延时成啥了。 |
|
h*******t
发帖数: 2679 | 21 我觉得这个问题是视频音频工程师的活，不是网络工程师的活。
udp
包子 |
|
H*L
发帖数: 124 | 22 Your problem is probably due to bad interaction between tcp delayed ack and
nagle's algorithm. Nagle's algorithm won't send another packet until its
last in flight packet is acked, if the current pkt is too small; on the
other hand , at the other end, tcp will only send every other ack due to the
delayed ack policy
If all your packets are small it's almost guaranteed that you ll ran into
the situation where nagle's algorithm's end is waiting for its previous ack,
and the delayed ack end is not s... 阅读全帖 |
|
|
|
i*****o
发帖数: 1714 | 25 这个问题已经解决了， 就是改一下ip route default initcwnd， default是3，我改
成20就好了。
关于这个问题的根源我已经说过， 就是linux上对tcp slow start的实现没有按通常的
要求去做。tcp slow start是为了避免congestion，省的一个新的session来了以后，
一下子传太多造成没有必要的drop frame和retransmission。公认的实现是start with
3x mss。就是说ethernet上可以一下子送1500＊3 ＝ 4500字节。4500字节对我来说就
是90个voice packet（差不多两秒的通话）足够用的了。可linux上写这个程序的人偷
懒，把slow start定义为start with 3 packets，不管这个packet里有多少字节。这样
我的应用就被卡注了。想想3g network round trip delay差不多在60ms－200ms之间，
200ms就是10个voice packet，可linux只给3个packet，所以就不断的drop frame（
voic... 阅读全帖 |
|
r****y
发帖数: 26819 | 26 那freebsd之类的其它系统是不是也跟linux一样？
with |
|
c*****e
发帖数: 3226 | 27 why do not you use open source rtp stack?
你这么写完全是闭门造车。 |
|
c*****e
发帖数: 3226 | 28 opensips 只有signal, 没rtp. |
|
|
|
N******K
发帖数: 10202 | 31 open source rtp stack 包括了tcp协议？ 把linux里面的就给屏蔽了？ |
|
l**n
发帖数: 7272 | 32 Does this problem exist in Windows or other platform (Android/ iOS)?
with |
|
|
