l**********2
发帖数: 728 | 1 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
要占住，中途不换座
网络输入输出。TCP协议。
benchmark，输入要严格限制在1M/s。误差正负5%以内。一小时以内的连续数据。
机器价格低于2W美元。（我个人认为可以加10-20%浮动，NOT A BIG DEAL)
单机。至多一小时数据量的半七马克，每三分钟的总延迟不超过三秒。
从美国时间12/12开始算，到12/17 23:59截止，共5天，三个工作日时间。
在此之前，双方主ID都不得再在版面上发帖讨论任何相关话题。
所有代码开源。可以代码先开源，半期马克之后再单独写单独测。
如魏做到，好虫自杀所有ID，不得再回买买提。
如魏没有做到，魏自杀ID，不得再回买买提。
如双方没有意见，请来签字确认。 |
l**********2
发帖数: 728 | 2 既然条件是好虫出的，我有一个个人建议，以免太不公平。就是三个工作日的限期，从
魏找到合适的服务器开始。
好虫，这个不过分吧？ |
b*******g
发帖数: 603 | 3 开发在哪里都行，deadline前代码先拿出来，再找服务器测试。
【在 l**********2 的大作中提到】
: 既然条件是好虫出的，我有一个个人建议，以免太不公平。就是三个工作日的限期，从
: 魏找到合适的服务器开始。
: 好虫，这个不过分吧？
|
l**********2
发帖数: 728 | 4 总得自己找个差不多的地方跑一下看看行不行的吧？
那要不然先代码拿出来，然后慢慢找服务器测试，末了只要有找到一台满足条件的服务
器通过了就算通过，如何？
【在 b*******g 的大作中提到】
: 开发在哪里都行，deadline前代码先拿出来，再找服务器测试。
|
b*******g
发帖数: 603 | 5 程序功能很简单，确认够快是他的事情了。
【在 l**********2 的大作中提到】
: 总得自己找个差不多的地方跑一下看看行不行的吧？
: 那要不然先代码拿出来，然后慢慢找服务器测试，末了只要有找到一台满足条件的服务
: 器通过了就算通过，如何？
|
t****n
发帖数: 263 | 6 我认为多少个client要定一下，别又出来个magical的前端可以转发所以的request。连
续数据是什么意思要更精确的定义下。输入必须完全random，client不能预处理
【在 l**********2 的大作中提到】
: 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
: 要占住，中途不换座
: 网络输入输出。TCP协议。
: benchmark，输入要严格限制在1M/s。误差正负5%以内。一小时以内的连续数据。
: 机器价格低于2W美元。（我个人认为可以加10-20%浮动，NOT A BIG DEAL)
: 单机。至多一小时数据量的半七马克，每三分钟的总延迟不超过三秒。
: 从美国时间12/12开始算，到12/17 23:59截止，共5天，三个工作日时间。
: 在此之前，双方主ID都不得再在版面上发帖讨论任何相关话题。
: 所有代码开源。可以代码先开源，半期马克之后再单独写单独测。
: 如魏做到，好虫自杀所有ID，不得再回买买提。
|
t****n
发帖数: 263 | 7 还有，有没有联票？没有让步太多了！
【在 l**********2 的大作中提到】
: 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
: 要占住，中途不换座
: 网络输入输出。TCP协议。
: benchmark，输入要严格限制在1M/s。误差正负5%以内。一小时以内的连续数据。
: 机器价格低于2W美元。（我个人认为可以加10-20%浮动，NOT A BIG DEAL)
: 单机。至多一小时数据量的半七马克，每三分钟的总延迟不超过三秒。
: 从美国时间12/12开始算，到12/17 23:59截止，共5天，三个工作日时间。
: 在此之前，双方主ID都不得再在版面上发帖讨论任何相关话题。
: 所有代码开源。可以代码先开源，半期马克之后再单独写单独测。
: 如魏做到，好虫自杀所有ID，不得再回买买提。
|
z****e
发帖数: 54598 | 8 原来吹说两万能够搞定一切
现在不过5k，12306并发可是上万的
而且是http，外加一个安全协议
你现在简化成一个tcp连接？
联票什么都不用做了
感觉这个计数器简直是搞笑来的 |
T*******e
发帖数: 4928 | 9 为什么要自杀？ 这都是什么呀。只剩一家之言，有什么好处。
如果魏写出来，证明他的设计是可行的。大家也可学习借鉴。
好虫为什么就不能发言了。
如果魏没写出来，那也只说明他的设计或实现有问题，
大家分析为什么写不出来就行了。魏为什么就不能发言了。
大家都是人，孰能无过。更不要说这都算不上过错。这是观点
不同。 争论归争论，为什么非你死我活，闹那么偏执。
【在 l**********2 的大作中提到】
: 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
: 要占住，中途不换座
: 网络输入输出。TCP协议。
: benchmark，输入要严格限制在1M/s。误差正负5%以内。一小时以内的连续数据。
: 机器价格低于2W美元。（我个人认为可以加10-20%浮动，NOT A BIG DEAL)
: 单机。至多一小时数据量的半七马克，每三分钟的总延迟不超过三秒。
: 从美国时间12/12开始算，到12/17 23:59截止，共5天，三个工作日时间。
: 在此之前，双方主ID都不得再在版面上发帖讨论任何相关话题。
: 所有代码开源。可以代码先开源，半期马克之后再单独写单独测。
: 如魏做到，好虫自杀所有ID，不得再回买买提。
|
z****e
发帖数: 54598 | 10 这里就不存在有仅限一个tcp连接的说法
老魏自己乱加的，可以限制带宽
但是不能限制连接数
这5k个几户必然是同时发生的连接
否则叫什么并发？
并发上万了都 |
|
|
z****e
发帖数: 54598 | 11 不说话了？
老魏又遁了
这种夹带的搞法真的很恶心啊
话不说清楚，故意留个小后门
玩点小孩子把戏 |
b*******g
发帖数: 603 | 12 服务器怎么写是他的事情，客户端怎么写是我的事情。总之是1M/s. |
t****n
发帖数: 263 | 13 那好多了。白担心了一阵。想他要是耍赖把所有票一股脑都用一个链接发过去，然后再
算，那就未免太简单了。现在这样基本肯定做不到。
【在 b*******g 的大作中提到】
: 服务器怎么写是他的事情，客户端怎么写是我的事情。总之是1M/s.
|
z****e
发帖数: 54598 | 14 老魏自己说的不算
从见证贴看
并没有说什么单一tcp连接
这个是偷改的 |
t**********1
发帖数: 550 | 15 请见证人再加上，单TCP是我第一贴就明说的。白纸黑字。 |
t****n
发帖数: 263 | 16 现在魏太监偷偷加了个单一链接的限制。
【在 b*******g 的大作中提到】
: 服务器怎么写是他的事情，客户端怎么写是我的事情。总之是1M/s.
|
z****e
发帖数: 54598 | 17
这还能请见证人加上？
见证人加任何东西都必需经过双方反复确认同意后方可
你能自行要求添加？
看这样子你是做不出12306了
好了，别吹那计数器了，好无聊诶
【在 t**********1 的大作中提到】
: 请见证人再加上，单TCP是我第一贴就明说的。白纸黑字。
|
t****n
发帖数: 263 | 18 少他妈扯淡。单一网卡才是好虫先提出来的条件。你丫给偷偷改了。跟你这怂货小人就
不该堵。
【在 t**********1 的大作中提到】
: 请见证人再加上，单TCP是我第一贴就明说的。白纸黑字。
|
z****e
发帖数: 54598 | 19 数据包的拼接本质上跟联票是一个道理
嘿嘿，所以古德霸会同意这么搞
原子性必需保证，否则还做什么？
12306都能做到的，做不到就不要吹了 |
t****n
发帖数: 263 | 20 我说傻叉如你的公司是怎么开下去的呢！原来是靠偷改合同这类的坑蒙拐骗啊。呵呵。
【在 t**********1 的大作中提到】
: 请见证人再加上，单TCP是我第一贴就明说的。白纸黑字。
|
|
|
l**********2
发帖数: 728 | 21 单一TCP链接。这个条件在魏的赌约贴里有，那个帖子原帖没有编辑过，
好虫是回帖里确认了的。
http://www.mitbbs.com/article_t/Programming/31459333.html
好虫，鉴于赵策和另一个你方ID对于这个条件有很大的不满，你要不要出来澄清一下这
个条件有没有？
因为你之前在第一个帖子里回帖确认过这个条件，所以按道理，是应该有的。我之前没
把这个加进来，是我的疏忽，引起了一些人的不满。
不如这样：如你在西海岸时间12/12 6pm之前，觉得这个条件你不能接受或者有异议，
那我们赌约就再议；如到那个时候没有听到你本人的异议，那赌约就照更新版的进行。
魏，你觉得这样如何？ |
l**********2
发帖数: 728 | 22 各方ID先不要开喷。单一TCP这个条件确实一开始有，好虫也默认了，这个是我的疏忽
，我没注意到原帖里有这么一条。原帖没有修改过。
另外我说过了，好虫本人对此似乎没有异议。跟赌局不相干的，我们影响不了，但是建
议在周四零点之前，停止无谓的叫骂。毕竟赌局已经开始了，你们不是参与人，也不是
做项目的人。 |
t****n
发帖数: 263 | 23 好虫提出条件的贴子里没有（可惜被删了）。是魏自己偷偷加上去的。藏在他的贴子的
中间，还好像一副就是好虫原来条件的样子。
【在 l**********2 的大作中提到】
: 单一TCP链接。这个条件在魏的赌约贴里有，那个帖子原帖没有编辑过，
: 好虫是回帖里确认了的。
: http://www.mitbbs.com/article_t/Programming/31459333.html
: 好虫，鉴于赵策和另一个你方ID对于这个条件有很大的不满，你要不要出来澄清一下这
: 个条件有没有？
: 因为你之前在第一个帖子里回帖确认过这个条件，所以按道理，是应该有的。我之前没
: 把这个加进来，是我的疏忽，引起了一些人的不满。
: 不如这样：如你在西海岸时间12/12 6pm之前，觉得这个条件你不能接受或者有异议，
: 那我们赌约就再议；如到那个时候没有听到你本人的异议，那赌约就照更新版的进行。
: 魏，你觉得这样如何？
|
l**********2
发帖数: 728 | 24 帖子如果编辑过，会显示 修改于什么时间
原贴应该是并没有编辑过。
【在 t****n 的大作中提到】
: 好虫提出条件的贴子里没有（可惜被删了）。是魏自己偷偷加上去的。藏在他的贴子的
: 中间，还好像一副就是好虫原来条件的样子。
|
t****n
发帖数: 263 | 25 我是说他用各种骗术让人没有注意到。我昨天也没注意到。还以为是好虫的单一网卡。
今天经人提醒才发现这个猫腻。
【在 l**********2 的大作中提到】
: 帖子如果编辑过，会显示 修改于什么时间
: 原贴应该是并没有编辑过。
|
t****n
发帖数: 263 | 26 另外就是魏昨天张嘴闭嘴只给10分钟考虑的。就是怕他的猫腻被发现。很常见的骗术
【在 t****n 的大作中提到】
: 我是说他用各种骗术让人没有注意到。我昨天也没注意到。还以为是好虫的单一网卡。
: 今天经人提醒才发现这个猫腻。
|
f******2
发帖数: 2455 | 27 如果不是好虫的马甲，你人品也挺下作。
好好的从口水战变成技术show hands，你非要搅和
【在 t****n 的大作中提到】
: 另外就是魏昨天张嘴闭嘴只给10分钟考虑的。就是怕他的猫腻被发现。很常见的骗术
|
t****n
发帖数: 263 | 28 还技术？你们配吗？先把linear scalability给大家show hands下吧！
【在 f******2 的大作中提到】
: 如果不是好虫的马甲，你人品也挺下作。
: 好好的从口水战变成技术show hands，你非要搅和
|
b*******g
发帖数: 603 | 29 哪里有说单一 TCP连接？只说了我开出的条件是网络输入网络输出，可以他的协议，但
是由我实现 client.
【在 l**********2 的大作中提到】
: 单一TCP链接。这个条件在魏的赌约贴里有，那个帖子原帖没有编辑过，
: 好虫是回帖里确认了的。
: http://www.mitbbs.com/article_t/Programming/31459333.html
: 好虫，鉴于赵策和另一个你方ID对于这个条件有很大的不满，你要不要出来澄清一下这
: 个条件有没有？
: 因为你之前在第一个帖子里回帖确认过这个条件，所以按道理，是应该有的。我之前没
: 把这个加进来，是我的疏忽，引起了一些人的不满。
: 不如这样：如你在西海岸时间12/12 6pm之前，觉得这个条件你不能接受或者有异议，
: 那我们赌约就再议；如到那个时候没有听到你本人的异议，那赌约就照更新版的进行。
: 魏，你觉得这样如何？
|
g****u
发帖数: 252 | 30 怎么没有写磁盘的要求？得要求老魏另外写一个程序，任意时刻拔电源，重启后这个程
序打印日志中已经卖出的车票,得与好虫对得上才行。 tcp连接数讨论过，老魏的设计
需要外围服务器聚合请求，所以最多几十个连接。但是一个链接测试用我觉得不是最合
理。如果两个链接，合起来能达到性能标准，我觉得就够了。
另外，如果好虫客户端太慢怎么办？
【在 l**********2 的大作中提到】
: 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
: 要占住，中途不换座
: 网络输入输出。TCP协议。
: benchmark，输入要严格限制在1M/s。误差正负5%以内。一小时以内的连续数据。
: 机器价格低于2W美元。（我个人认为可以加10-20%浮动，NOT A BIG DEAL)
: 单机。至多一小时数据量的半七马克，每三分钟的总延迟不超过三秒。
: 从美国时间12/12开始算，到12/17 23:59截止，共5天，三个工作日时间。
: 在此之前，双方主ID都不得再在版面上发帖讨论任何相关话题。
: 所有代码开源。可以代码先开源，半期马克之后再单独写单独测。
: 如魏做到，好虫自杀所有ID，不得再回买买提。
|
|
|
t****n
发帖数: 263 | 31 如果能聚合成一个链接的话还用他的计数器干什么，聚合的server顺便就把他的计数器
给做了。还要发给另一个server做这种简单的工作不是有病吗？需求阉割这样，里面可
以cheating的地方太多了。我不看好这个赌约，最后十有八九是
一场闹剧。
【在 g****u 的大作中提到】
: 怎么没有写磁盘的要求？得要求老魏另外写一个程序，任意时刻拔电源，重启后这个程
: 序打印日志中已经卖出的车票,得与好虫对得上才行。 tcp连接数讨论过，老魏的设计
: 需要外围服务器聚合请求，所以最多几十个连接。但是一个链接测试用我觉得不是最合
: 理。如果两个链接，合起来能达到性能标准，我觉得就够了。
: 另外，如果好虫客户端太慢怎么办？
|
t**********1
发帖数: 550 | 32 好虫，看你究竟有没有廉耻了。
我说过，合理数量的多TCP不能改变基本事实。
你不能连上只发一个请求就断开。
这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的response。
【在 b*******g 的大作中提到】
: 哪里有说单一 TCP连接？只说了我开出的条件是网络输入网络输出，可以他的协议，但
: 是由我实现 client.
|
a****i
发帖数: 1182 | 33 就是，这么个东西也能叫12306？
需求到底是什么？TW可是说的每秒出票多少，是吧
怎么样算出票？从抢到票到付款、确认，然后出票，这么一套下来，用单机？
5M票每秒？
要是变成占票就行了，这还能算个啥？
【在 t****n 的大作中提到】
: 如果能聚合成一个链接的话还用他的计数器干什么，聚合的server顺便就把他的计数器
: 给做了。还要发给另一个server做这种简单的工作不是有病吗？需求阉割这样，里面可
: 以cheating的地方太多了。我不看好这个赌约，最后十有八九是
: 一场闹剧。
|
l**********2
发帖数: 728 | 34 魏，好虫对着一条有异议 要不你们再协商一下？
这是目前唯一de分歧了。
【在 b*******g 的大作中提到】
: 哪里有说单一 TCP连接？只说了我开出的条件是网络输入网络输出，可以他的协议，但
: 是由我实现 client.
|
t**********1
发帖数: 550 | 35 我刚刚回帖。而且还另开一题。
【在 l**********2 的大作中提到】
: 魏，好虫对着一条有异议 要不你们再协商一下？
: 这是目前唯一de分歧了。
|
l**********2
发帖数: 728 | 36 大家时间都有限，也没人领工资做这个 不可能做的和现实世界需求一样。
好虫 你对于魏放宽tcp的要求是否同意？你之前攻击的点也不在tcp连接上。去火你是
对的，.100 tcp连接应该可以检测出来了。 |
b*******g
发帖数: 603 | 37 哪里有说单一 TCP连接？只说了我开出的条件是网络输入网络输出，可以他的协议，但
是由我实现 client. 怎么实现当然是我的自由，只要不超过 1Mps.
【在 l**********2 的大作中提到】
: 单一TCP链接。这个条件在魏的赌约贴里有，那个帖子原帖没有编辑过，
: 好虫是回帖里确认了的。
: http://www.mitbbs.com/article_t/Programming/31459333.html
: 好虫，鉴于赵策和另一个你方ID对于这个条件有很大的不满，你要不要出来澄清一下这
: 个条件有没有？
: 因为你之前在第一个帖子里回帖确认过这个条件，所以按道理，是应该有的。我之前没
: 把这个加进来，是我的疏忽，引起了一些人的不满。
: 不如这样：如你在西海岸时间12/12 6pm之前，觉得这个条件你不能接受或者有异议，
: 那我们赌约就再议；如到那个时候没有听到你本人的异议，那赌约就照更新版的进行。
: 魏，你觉得这样如何？
|
t****n
发帖数: 263 | 38 好虫不是也要公布他client的源码吗？“只发一个请求就断开”这种把戏大家都能看的
出来。到时候我第一个鄙视他。
如果你们同意放弃单一链接的要求话（100个我觉得够了），我也可以保证在这期间不
＊主动＊对你恶语相向。不提linear scalability，直到结果出来。
response。
【在 t**********1 的大作中提到】
: 好虫，看你究竟有没有廉耻了。
: 我说过，合理数量的多TCP不能改变基本事实。
: 你不能连上只发一个请求就断开。
: 这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的response。
|
t**********1
发帖数: 550 | 39 你这个就不要脸了。你要是每一次连接送一个请求难道我也要伺候？
我说单一 TCP主要也是这个原因。外围机也是内部系统。频繁连接的可以默认故障直接
封IP的。
别废话了。要脸的话，我已经放宽条件了，你应该接受。
【在 b*******g 的大作中提到】
: 哪里有说单一 TCP连接？只说了我开出的条件是网络输入网络输出，可以他的协议，但
: 是由我实现 client. 怎么实现当然是我的自由，只要不超过 1Mps.
|
l**********2
发帖数: 728 | |
|
|
t**********1
发帖数: 550 | 41 我已经明确表态了。
好虫，看你究竟有没有廉耻了。
我说过，合理数量的多TCP不能改变基本事实。
你不能连上只发一个请求就断开。
这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。
现在就看好虫的了。
【在 t****n 的大作中提到】
: 好虫不是也要公布他client的源码吗？“只发一个请求就断开”这种把戏大家都能看的
: 出来。到时候我第一个鄙视他。
: 如果你们同意放弃单一链接的要求话（100个我觉得够了），我也可以保证在这期间不
: ＊主动＊对你恶语相向。不提linear scalability，直到结果出来。
:
: response。
|
b*******g
发帖数: 603 | 42 单一 tcp是不可能的，你的web 前端撑不住，100台机器并发连过来就差不多了。
【在 t**********1 的大作中提到】
: 你这个就不要脸了。你要是每一次连接送一个请求难道我也要伺候？
: 我说单一 TCP主要也是这个原因。外围机也是内部系统。频繁连接的可以默认故障直接
: 封IP的。
: 别废话了。要脸的话，我已经放宽条件了，你应该接受。
|
t****n
发帖数: 263 | 43 好虫不是回答用他们公司blog里提到的类似的方法测吗？那个里头有60个clients，我
也不相信clients会断开链接，等我再看看。
【在 t**********1 的大作中提到】
: 我已经明确表态了。
: 好虫，看你究竟有没有廉耻了。
: 我说过，合理数量的多TCP不能改变基本事实。
: 你不能连上只发一个请求就断开。
: 这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
: response。
: 现在就看好虫的了。
|
t**********1
发帖数: 550 | 44 废话少说。请你确认。
这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。
【在 b*******g 的大作中提到】
: 单一 tcp是不可能的，你的web 前端撑不住，100台机器并发连过来就差不多了。
|
b*******g
发帖数: 603 | 45 特意断开连接不会。
【在 t**********1 的大作中提到】
: 废话少说。请你确认。
: 这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
: response。
|
t**********1
发帖数: 550 | 46 这么说你同意了？请明确表态。
【在 b*******g 的大作中提到】
: 特意断开连接不会。
|
b*******g
发帖数: 603 | 47 反正我就是每个机器起个 theadpool，并发发 request, 调到单机能到1万为止 |
t**********1
发帖数: 550 | 48 请你直接确认一下条件：
这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。
【在 b*******g 的大作中提到】
: 反正我就是每个机器起个 theadpool，并发发 request, 调到单机能到1万为止
|
d****r
发帖数: 300 | 49 如果是指enable http keepalive的话，可能默认server to server只有一个或very
limited number的http connection.
这事情总算向postive方向靠近一些，大家努力，说不准还能化敌为友。
【在 t****n 的大作中提到】
: 好虫不是回答用他们公司blog里提到的类似的方法测吗？那个里头有60个clients，我
: 也不相信clients会断开链接，等我再看看。
|
b*******g
发帖数: 603 | 50 一般是 limit number，不会超过20个，但也不会限制一个。多个是为了不等在连接上
阻塞，如果它是一微妙的响应，单个当然也可以。
【在 d****r 的大作中提到】
: 如果是指enable http keepalive的话，可能默认server to server只有一个或very
: limited number的http connection.
: 这事情总算向postive方向靠近一些，大家努力，说不准还能化敌为友。
|
|
|
t**********1
发帖数: 550 | 51 好虫，请你直接确认。省得以后再生事端。
请你直接确认一下条件：
这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。
【在 b*******g 的大作中提到】
: 一般是 limit number，不会超过20个，但也不会限制一个。多个是为了不等在连接上
: 阻塞，如果它是一微妙的响应，单个当然也可以。
|
t****n
发帖数: 263 | 52 我觉得好虫的意思是说如果一个链接发不了10k／s，那他就要更多的链接。
【在 t**********1 的大作中提到】
: 请你直接确认一下条件：
: 这样好吧？最多不超过100TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
: response。
|
b*******g
发帖数: 603 | 53 是这个理，如果响应快，自然连接少就够了。
【在 t****n 的大作中提到】
: 我觉得好虫的意思是说如果一个链接发不了10k／s，那他就要更多的链接。
|
t**********1
发帖数: 550 | 54 这话说的，如果别人单TCP都能送1M/s请求，你claim只能每秒一个，那不又是1M TCP么？
我可以证明单TCP能handle流量。你必须确保如下约定：
最多不超过100TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。
【在 b*******g 的大作中提到】
: 是这个理，如果响应快，自然连接少就够了。
|
d****r
发帖数: 300 | 55 这是合理的要求，上load，多线程多机器是需要的。现在有点鸡和蛋的关系，如果老魏
够快，德霸可能不需要这么多connection。反之亦然。要不就从100connection 开始?
【在 b*******g 的大作中提到】
: 是这个理，如果响应快，自然连接少就够了。
|
t****n
发帖数: 263 | 56 你未免太小人之心了。code放在那，猫腻自然看的出来，特别是这种明显的。关键问题
是到时候你别说是client太慢导致你到不了1M／s的。
么？
【在 t**********1 的大作中提到】
: 这话说的，如果别人单TCP都能送1M/s请求，你claim只能每秒一个，那不又是1M TCP么？
: 我可以证明单TCP能handle流量。你必须确保如下约定：
: 最多不超过100TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
: response。
|
t**********1
发帖数: 550 | 57 别扯这个蛋。
我说了，我证明一个TCP就足够handle load。大不了写一个client。
古德霸必须把TCP限制在100以内。
【在 d****r 的大作中提到】
: 这是合理的要求，上load，多线程多机器是需要的。现在有点鸡和蛋的关系，如果老魏
: 够快，德霸可能不需要这么多connection。反之亦然。要不就从100connection 开始?
|
b*******g
发帖数: 603 | 58 因为前端过来的请求，web服务要同步处理，光发包可以很快，但前端还要干别的活。
而且你要求同步呀。
么？
【在 t**********1 的大作中提到】
: 这话说的，如果别人单TCP都能送1M/s请求，你claim只能每秒一个，那不又是1M TCP么？
: 我可以证明单TCP能handle流量。你必须确保如下约定：
: 最多不超过100TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
: response。
|
t**********1
发帖数: 550 | 59 外围机不一定直接run web server。
100 TCP已经很多了。如果不设限制，你就会用100万。
必须有一个上限。我已经很reasonable了。
最多不超过100TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。
【在 b*******g 的大作中提到】
: 因为前端过来的请求，web服务要同步处理，光发包可以很快，但前端还要干别的活。
: 而且你要求同步呀。
:
: 么？
|
b*******g
发帖数: 603 | 60 我不知道你到底要说什么，IO怎么做的 blog我也示例了，就是上了个 cluster多线程
并发。百万连接当然不会，但一台机器要几个取决于服务器响应多快了。
【在 t**********1 的大作中提到】
: 外围机不一定直接run web server。
: 100 TCP已经很多了。如果不设限制，你就会用100万。
: 必须有一个上限。我已经很reasonable了。
: 最多不超过100TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
: response。
|
|
|
t****n
发帖数: 263 | 61 “我说了，我证明一个TCP就足够handle load”。真不知该说你什么好。算了，我忍。
要不设几档。同样的client，100，200，400链接或更多都测一下。
算了，我不掺和了
【在 t**********1 的大作中提到】
: 别扯这个蛋。
: 我说了，我证明一个TCP就足够handle load。大不了写一个client。
: 古德霸必须把TCP限制在100以内。
|
t**********1
发帖数: 550 | 62 你是不是说，你的test client写的越烂，你就越占便宜？
你认为这样合理么？如果我一个Client就能做到。最多限制你用100个client。已经很
合理了。
现实中，如果团队里有人做外围机连接很烂，可以直接 fire 掉了。
【在 b*******g 的大作中提到】
: 我不知道你到底要说什么，IO怎么做的 blog我也示例了，就是上了个 cluster多线程
: 并发。百万连接当然不会，但一台机器要几个取决于服务器响应多快了。
|
b*******g
发帖数: 603 | 63 太监还同意加同步写盘，这也是合理要求，不能断电就没了。他要 transaction,
durability还是要的。 |
t**********1
发帖数: 550 | 64 别不要脸。我没那么快的同步盘。
我也没说过要加上。我说过了，抢票机可以不记录状态。
【在 b*******g 的大作中提到】
: 太监还同意加同步写盘，这也是合理要求，不能断电就没了。他要 transaction,
: durability还是要的。
|
b*******g
发帖数: 603 | 65 首先你觉得有单机能处理百万的网页？
所以 100是至少的，至于每个要多少取决于你的服务器多快呀。
【在 t**********1 的大作中提到】
: 你是不是说，你的test client写的越烂，你就越占便宜？
: 你认为这样合理么？如果我一个Client就能做到。最多限制你用100个client。已经很
: 合理了。
: 现实中，如果团队里有人做外围机连接很烂，可以直接 fire 掉了。
|
t**********1
发帖数: 550 | 66 好虫，这样好吧？最多不能超过200TCP。
最多不超过200TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。 |
t**********1
发帖数: 550 | 67 给你提高到200了。
我有单机能处理千万的HTTP。没必要给你看罢了。
【在 b*******g 的大作中提到】
: 首先你觉得有单机能处理百万的网页？
: 所以 100是至少的，至于每个要多少取决于你的服务器多快呀。
|
b*******g
发帖数: 603 | 68 你刚刚说了写盘不影响性能。你也说了你的计数器支持 transaction, 这就要反悔了吗？
【在 t**********1 的大作中提到】
: 别不要脸。我没那么快的同步盘。
: 我也没说过要加上。我说过了，抢票机可以不记录状态。
|
t**********1
发帖数: 550 | 69 赌局就是赌局。难道不影响性能我就一定要加上？
给你提高到200TCP了。请确认。
好虫，这样好吧？最多不能超过200TCP。
最多不超过200TCP。TCP持续连接不得少于1分钟。
在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
response。
吗？
【在 b*******g 的大作中提到】
: 你刚刚说了写盘不影响性能。你也说了你的计数器支持 transaction, 这就要反悔了吗？
|
b*******g
发帖数: 603 | 70 你要跟我谈条件我自然也可以谈条件，何况我的要求很合理。本来就是说好了你写
server， 我写 client，你可没限制我 client怎么写。
【在 t**********1 的大作中提到】
: 赌局就是赌局。难道不影响性能我就一定要加上？
: 给你提高到200TCP了。请确认。
: 好虫，这样好吧？最多不能超过200TCP。
: 最多不超过200TCP。TCP持续连接不得少于1分钟。
: 在收到全部response之前断开连接是client的责任。server不负责回放。事实上的商业
: 规则是支付系统反正最终会通知用户。但是我们的demo则直接扔掉未传输完的
: response。
:
: 吗？
|
|
|
t**********1
发帖数: 550 | 71 你没资格谈条件。
我的赌局你已经答应了。
我给你增加到200 TCP已经照顾你了。
难道你client写的烂就算你赢了？
人要要脸。否则没人瞧得起你。
【在 b*******g 的大作中提到】
: 你要跟我谈条件我自然也可以谈条件，何况我的要求很合理。本来就是说好了你写
: server， 我写 client，你可没限制我 client怎么写。
|
l**********2
发帖数: 728 | 72 写盘这个不管能做不能做，不在这次范围以内
好虫，要不你提一个TCP链接的折衷方案吧。或者说你想怎么弄，旧的链接BLOCK多久你
在客户端起新TCP，这样魏如果同意也可以，毕竟反正你不会恶意起链接断连接，如果
他服务器够快，你的标准他又接受，可以把TCP链接控制在一个数字以下。 |
t**********1
发帖数: 550 | 73 TCP数量必须有确定上限。
到时候他的client写的烂是他的事情。如果其他网友能够复制结果。就应该算他输。
【在 l**********2 的大作中提到】
: 写盘这个不管能做不能做，不在这次范围以内
: 好虫，要不你提一个TCP链接的折衷方案吧。或者说你想怎么弄，旧的链接BLOCK多久你
: 在客户端起新TCP，这样魏如果同意也可以，毕竟反正你不会恶意起链接断连接，如果
: 他服务器够快，你的标准他又接受，可以把TCP链接控制在一个数字以下。
|
l**********2
发帖数: 728 | 74 你是全同步呀，如果你200个上限到了，CLIENT塞爆了，都在等回复（假设你处理的不
够快），那他应该怎么搞？CLIENT端BLOCK住？
【在 t**********1 的大作中提到】
: TCP数量必须有确定上限。
: 到时候他的client写的烂是他的事情。如果其他网友能够复制结果。就应该算他输。
|
b*******g
发帖数: 603 | 75 我就这意思，他机器够快就行，但我不会在 client端 throttling.
【在 l**********2 的大作中提到】
: 你是全同步呀，如果你200个上限到了，CLIENT塞爆了，都在等回复（假设你处理的不
: 够快），那他应该怎么搞？CLIENT端BLOCK住？
|
t**********1
发帖数: 550 | 76 我是全异步。TCP本来就有flow control。
我可以开源client，证明200个client都不会阻塞。只要总message rate持续保持1M/s
+- 5%。
【在 l**********2 的大作中提到】
: 你是全同步呀，如果你200个上限到了，CLIENT塞爆了，都在等回复（假设你处理的不
: 够快），那他应该怎么搞？CLIENT端BLOCK住？
|
t**********1
发帖数: 550 | 77 别忘了1M/s +- 5%的条件。这是你client应该遵守的。
如果你乱发，我server当然要throttle。难道允许你一秒送1000万？
【在 b*******g 的大作中提到】
: 我就这意思，他机器够快就行，但我不会在 client端 throttling.
|
t****n
发帖数: 263 | 78 要不这样，好虫保障同样的client在单链接情况下发出最少5k/s的请求。如果在多链接
情况下server handle不了那就别怪client加链接了
s
【在 t**********1 的大作中提到】
: 我是全异步。TCP本来就有flow control。
: 我可以开源client，证明200个client都不会阻塞。只要总message rate持续保持1M/s
: +- 5%。
|
b*******g
发帖数: 603 | 79 等会，你可说的一直是同步，client自然要等到有 response.
s
【在 t**********1 的大作中提到】
: 我是全异步。TCP本来就有flow control。
: 我可以开源client，证明200个client都不会阻塞。只要总message rate持续保持1M/s
: +- 5%。
|
t**********1
发帖数: 550 | 80 不需要。 client可以一直送，server会异步返回。
协议里面有REQID的。
做同步的没意思。
【在 b*******g 的大作中提到】
: 等会，你可说的一直是同步，client自然要等到有 response.
:
: s
|
|
|
b*******g
发帖数: 603 | 81 起始200，够快不加，server没有及时反馈我就再加连接。
【在 t****n 的大作中提到】
: 要不这样，好虫保障同样的client在单链接情况下发出最少5k/s的请求。如果在多链接
: 情况下server handle不了那就别怪client加链接了
:
: s
|
l**********2
发帖数: 728 | 82 折衷一下吧。
开始100.加到最多200.再多就算延迟。TIMEOUT算延迟。
你们可以估算一个TIMEOUT的效率。
【在 b*******g 的大作中提到】
: 起始200，够快不加，server没有及时反馈我就再加连接。
|
t**********1
发帖数: 550 | 83 起始20。最多200.
我可以证明从1-500 TCP都能及时反馈。
给你上限200.我都说了，异步的。你只要控制住request rate就好了。
【在 b*******g 的大作中提到】
: 起始200，够快不加，server没有及时反馈我就再加连接。
|
t**********1
发帖数: 550 | 84 同意。他GC导致的TIMEOUT不能怪我。
【在 l**********2 的大作中提到】
: 折衷一下吧。
: 开始100.加到最多200.再多就算延迟。TIMEOUT算延迟。
: 你们可以估算一个TIMEOUT的效率。
|
b*******g
发帖数: 603 | 85 你可是一直鼓吹同步架构，现在要反悔了吗？ client 是我写的， reference的 blog
也是我拿出来的。
【在 t**********1 的大作中提到】
: 不需要。 client可以一直送，server会异步返回。
: 协议里面有REQID的。
: 做同步的没意思。
|
t**********1
发帖数: 550 | 86 同步异步不是一回事么？
反正你每个single TCP的req先后次序我都要尊重。
但是多个TCP，短时间内，哪个先发出，哪个我先收到，咱们都不能控制了。
说白了，我做异步，单连接throughput处理就大了几个数量级了。而且更难做。你岂不
是赚了？
blog
【在 b*******g 的大作中提到】
: 你可是一直鼓吹同步架构，现在要反悔了吗？ client 是我写的， reference的 blog
: 也是我拿出来的。
|
b*******g
发帖数: 603 | 87 我不管你怎么做，反正 client是我写的。合理模拟从 web server过去就是。
【在 t**********1 的大作中提到】
: 同步异步不是一回事么？
: 反正你每个single TCP的req先后次序我都要尊重。
: 但是多个TCP，短时间内，哪个先发出，哪个我先收到，咱们都不能控制了。
: 说白了，我做异步，单连接throughput处理就大了几个数量级了。而且更难做。你岂不
: 是赚了？
:
: blog
|
t**********1
发帖数: 550 | 88 每个外围机只能建一个TCP。
我给了你200个外围机的指标了。
跟web server有啥关系？
【在 b*******g 的大作中提到】
: 我不管你怎么做，反正 client是我写的。合理模拟从 web server过去就是。
|
d****r
发帖数: 300 | 89 以上大家都是理性讨论，先赞一个！
【在 b*******g 的大作中提到】
: 我不管你怎么做，反正 client是我写的。合理模拟从 web server过去就是。
|
b*******g
发帖数: 603 | 90 我说了，你够快，一个 TCP当然可以。我在 client要 log 结果和 timestamp。才能验
证准确性。
【在 t**********1 的大作中提到】
: 每个外围机只能建一个TCP。
: 我给了你200个外围机的指标了。
: 跟web server有啥关系？
|
|
|
t**********1
发帖数: 550 | 91 随你便，server端超过500 TCP我会自动拒绝。
【在 b*******g 的大作中提到】
: 我说了，你够快，一个 TCP当然可以。我在 client要 log 结果和 timestamp。才能验
: 证准确性。
|
b*******g
发帖数: 603 | 92 同步等待我才能确认包哪个先到，才能确认正确性。
【在 t**********1 的大作中提到】
: 随你便，server端超过500 TCP我会自动拒绝。
|
t**********1
发帖数: 550 | 93 异步是一样的。因为你可以送REQID。
你可以验证同一个连接，如果你的REQID单调递增，我返回的REQID也是。
【在 b*******g 的大作中提到】
: 同步等待我才能确认包哪个先到，才能确认正确性。
|
g****u
发帖数: 252 | 94 我觉得这个没问题。高吞吐量pipeline是必要的。
客户端拿到返回写到日志里离线慢慢验证正确性就行。
【在 t**********1 的大作中提到】
: 异步是一样的。因为你可以送REQID。
: 你可以验证同一个连接，如果你的REQID单调递增，我返回的REQID也是。
|
b*******g
发帖数: 603 | 95 我要确认的是到服务器的先后顺序，不是从 client出去的先后顺序。
【在 t**********1 的大作中提到】
: 异步是一样的。因为你可以送REQID。
: 你可以验证同一个连接，如果你的REQID单调递增，我返回的REQID也是。
|
t**********1
发帖数: 550 | 96 同一个TCP client，从client出去的先后顺序和到服务器的先后顺序一模一样。所以我
才会支持REQID。
不同的TCP client之间，谁也控制不了。
【在 b*******g 的大作中提到】
: 我要确认的是到服务器的先后顺序，不是从 client出去的先后顺序。
|
h**********c
发帖数: 4120 | 97 你不如放在github上，大家可以看revision |
b*******g
发帖数: 603 | 98 行，有reqid可以。
【在 t**********1 的大作中提到】
: 同一个TCP client，从client出去的先后顺序和到服务器的先后顺序一模一样。所以我
: 才会支持REQID。
: 不同的TCP client之间，谁也控制不了。
|
q*c
发帖数: 9453 | 99 卧槽，单机处理 10M http request? 你不是开玩笑？
【在 t**********1 的大作中提到】
: 给你提高到200了。
: 我有单机能处理千万的HTTP。没必要给你看罢了。
|
t**********1
发帖数: 550 | 100 1M req/s, 10M websocket long poll
【在 q*c 的大作中提到】
: 卧槽，单机处理 10M http request? 你不是开玩笑？
|
|
|
h*c
发帖数: 45 | 101 等一下，10M long poll with 1M RPS on single server? OK, what hardware spec
do you have for that? Did you ever achieve that benchmark?
我不关心12306，但是这个只要不是吹牛逼我立刻拜师。
【在 t**********1 的大作中提到】
: 1M req/s, 10M websocket long poll
|
q*c
发帖数: 9453 | 102 尼玛我们当年用 nodejs Long poll 等待链接倒是可以上百万，但是 active 的几千系
统就不行了。
当然我们那个是个虚拟机， 也许老魏的实体机性能超越 100 倍？
spec
【在 h*c 的大作中提到】
: 等一下，10M long poll with 1M RPS on single server? OK, what hardware spec
: do you have for that? Did you ever achieve that benchmark?
: 我不关心12306，但是这个只要不是吹牛逼我立刻拜师。
|
h*c
发帖数: 45 | 103 你那个c1m的与硬件参数是什么？测试连接方式是什么？光是连1m不掉链子就已经很牛
逼了。
active的到底有几千？latency是多少？
【在 q*c 的大作中提到】
: 尼玛我们当年用 nodejs Long poll 等待链接倒是可以上百万，但是 active 的几千系
: 统就不行了。
: 当然我们那个是个虚拟机， 也许老魏的实体机性能超越 100 倍？
:
: spec
|
l******o
发帖数: 144 | 104 三分钟总延迟三秒是什么意思？每秒1M个request，三分钟就是180M个request。这180M
个request总延迟3秒，所以平均每个request延迟16ns？
5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
要占住，中途不换座
网络输入输出。TCP协议。
benchmark，输入要严格限制在1M/s。误差正负5%以内。一小时以内的连续数据。
机器价格低于2W美元。（我个人认为可以加10-20%浮动，NOT A BIG DEAL)
单机。至多一小时数据量的半七马克，每三分钟的总延迟不超过三秒。
从美国时间12/12开始算，到12/17 23:59截止，共5天，三个工作日时间。
在此之前，双方主ID都不得再在版面上发帖讨论任何相关话题。
所有代码开源。可以代码先开源，半期马克之后再单独写单独测。
如魏做到，好虫自杀所有ID，不得再回买买提。
如魏没有做到，魏自杀ID，不得再回买买提。
如双方没有意见，请来签字确认。
（12/12更新）单一TCP链接。这个条件在魏的赌约贴里有，那个帖子原帖没有编辑过，
好虫是回帖里确认了的。
http://www.mitbbs.com/article_t/Programming/31459333.html
好虫，鉴于赵策和另一个你方ID对于这个条件有很大的不满，你要不要出来澄清一下这
个条件有没有？
因为你之前在第一个帖子里回帖确认过这个条件，所以按道理，是应该有的。我之前没
把这个加进来，是我的疏忽，引起了一些人的不满。
不如这样：如你在西海岸时间12/12 6pm之前，觉得这个条件你不能接受或者有异议，
那我们赌约就再议；如到那个时候没有听到你本人的异议，那赌约就照更新版的进行。
魏，你觉得这样如何？
再更新一下双方似乎都没有异议的步骤：魏在周三 23：59之前，交代码，开源。作为
见证人，这个23：59是西海岸还是东海岸时间，不重要。三个小时不会怎么着。
如需要测试用服务器，魏自己解决。交完代码以后，好虫写客户端来测试，测试需满足
上述的基础条件，其余不限。大家一起找服务器来跑。这个时间不计算在三天以内。
如好虫写不出测试用客户端，视为好虫负。
只要找到任一服务器，其市场价格在2W美元（+/- 10%) 以内，可以通过好虫写的客户
端测试，则魏胜。
如在足够长的时间内，找不到此服务器可以通过测试，则好虫胜。
【在 l**********2 的大作中提到】
: 5000车次，每车次10站，3000票。输入车次，上车下车站，给回有 票没票信 息，有票
: 要占住，中途不换座
: 网络输入输出。TCP协议。
: benchmark，输入要严格限制在1M/s。误差正负5%以内。一小时以内的连续数据。
: 机器价格低于2W美元。（我个人认为可以加10-20%浮动，NOT A BIG DEAL)
: 单机。至多一小时数据量的半七马克，每三分钟的总延迟不超过三秒。
: 从美国时间12/12开始算，到12/17 23:59截止，共5天，三个工作日时间。
: 在此之前，双方主ID都不得再在版面上发帖讨论任何相关话题。
: 所有代码开源。可以代码先开源，半期马克之后再单独写单独测。
: 如魏做到，好虫自杀所有ID，不得再回买买提。
|
i**i
发帖数: 1500 | 105 10M websocket long poll 啥意思？
websocket 是 http 的升级版，直接支持双向，不存在long poll的事. 直接websocket
的干活？10M怎解？
【在 t**********1 的大作中提到】
: 1M req/s, 10M websocket long poll
|
i**i
发帖数: 1500 | |
q*c
发帖数: 9453 | 107 早忘了，测试连接的办法？就是客户端发包能收到处理结果啊。
大概。1～2 千就不行了. 还是 ejabberd 好一点。 我就说要用轮子，一般比自己的牛
叉。
【在 h*c 的大作中提到】
: 你那个c1m的与硬件参数是什么？测试连接方式是什么？光是连1m不掉链子就已经很牛
: 逼了。
: active的到底有几千？latency是多少？
|
s**y
发帖数: 151 | |
b***e
发帖数: 1419 | 109 ejabberd好像不能穿透防火墙。防火墙后好像只有http(s)能行。
【在 q*c 的大作中提到】
: 早忘了，测试连接的办法？就是客户端发包能收到处理结果啊。
: 大概。1～2 千就不行了. 还是 ejabberd 好一点。 我就说要用轮子，一般比自己的牛
: 叉。
|
