陌陌通讯协议的学习

陌陌发展刚开始由于规模小,30-40W的连接数(包括Android后台长连接用户),也使用XMPP;由于XMPP的缺点:流量大(基于XML),不可靠(为传统固定网络设计,没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景),交互复杂(登陆需5-6次,尤其是TLS握手);XMPP丢消息的根本原因:服务端和客户端处于“半关闭”状态,客户端假连接状态,服务端有收不到回执;Server端连接层和逻辑层代码没有解耦分离,常常重启导致不可用。

消息中转:

连接层(Connector链接集群)

连接层的作用:只做消息转发 设计原则简单/异步 允许随时重启更新/只允许晚上重启/不允许重启断线 单台压测试连接数70W;现状:5亿用户,月活5000W+,连接数1200W+;

逻辑层(Logic逻辑集群)

用户会话验证 消息存取 异步队列 随时重启

通讯协议设计:

安全性要求 流量要求 传输要求可靠(不会丢消息) 高效(弱网络快速的收发) 易于扩展

通讯协议:

常见协议XMPP/SIP 缺点:流量大,不可靠,交互复杂

采用私有通讯协议,目标:

高效,弱网络快速收发; 可靠,不会丢消息; 易于扩展; 参考协议格式:REDIS协议;

Redis协议:

下面都是用Redis协议来描述逻辑

Read Redis Command

基于队列的消息协议

基于队列的交互

传统的IM协议 前提是基于网线、WiFI,网络延迟极小 移动网络下,交互及其费时,服务器要维护每个状态容易出错

基于版本号的消息协议

基于版本号的交互

针对弱网络的优化协议

消息通过版本号维护顺序 新消息到达,Server只负责push通知 Client收到轻量的msg-psh后发生同步请求 Server按照版本号连续发送msg Client告诉Server收到的最后的版本

监控

核心的长连接只用于传输轻量的实时数据,图片、语音等都开新的TCP或HTTP连接;一切就绪后,最重要的就是监控,写一个APP查看所有的运营状态,每天观察; […]

微信通讯协议的学习

微信协议概览

微信传输协议,官方公布甚少,在微信技术总监所透漏PPT《微信之道—至简》文档中,有所体现。

微信从2011年1月发布以来,在一年之内实现了上亿用户,千万级在线,在苹果中国区App Store月下载量排行第一。 腾讯把微信的成功总结为“三位一体”,即产品的精准,项目的敏捷,以及技术的支撑。 敏捷就是试错法,用最快的迭代速度不断追求卓越。敏捷是一种态度,允许发布前十分钟的变更,并给予产品决策以最大的自由度。

微信使用的同步协议叫做SYNC,参考了微软的ActiveSync YNchronous ommunication:同步通信。没有数据发送时,传输线处于MARK状态。为了表示数据传输的开始,发送方先发送一个或两个特殊字符,该字符称为同步字符。当发送方和接收方达到同步后,就可以一个字符接一个字符地发送一大块数据,而不再需要用起始位和停止位了,这样可以明显地提高数据的传输速率。采用同步方式传送数据时,在发送过程中,收发双方还必须用一个时钟进行协调,用于确定串行传输中每一位的位置。接收数据时,接收方可利用同步字符将内部时钟与发送方保持同步,然后将同步字符后面的数据逐位移入,并转换成并行格式,供CPU读取,直至收到结束符为止。用一个Key来实现状态同步。这样一种协议在后台实现上比业界通用方案要复杂许多,但是能把客户端的实现大大简化,同时在很大程度上能够满足iPhone,安卓,塞班等多个操作系统的不同需求。

微信秉承“重后台轻客户端”的思路,因为客户端安装在用户手机上,变更成本很高;而后台则可以实现迅速的变更,在不发新版本的情况下实现新功能。以下是一个例子:微信的最初版本是不支持群聊的,第二个版本支持了群聊,但第一版客户端仍然可以在后台的变更处理之下参与群聊,只是不能够发起群聊而已。

其服务器端目前获知的几部分分别是三网专用网关服务器、登陆服务器组、负载均衡服务器组,主动推送服务器组、后台数据转换服务器组、存储阵列等几部分。由于目前没有任何能够直接从客户端保存至服务器端的功能,推测其服务方并没有用于数据记录的数据库服务器,而是在登陆服务器组中集成了用户数据库,用来记录用户授权。

因张小龙做邮箱Foxmail起家,继而又做了QQ Mail等,QQ Mail是国内第一个支持Exchange ActiveSync协议的免费邮箱,基于其从业背景,微信从一开始就采取基于ActiveSync的修改版状态同步协议Sync,也就再自然不过了。一句话:增量式、按序、可靠的状态同步传输的微信协议。

Microsoft Exchange Active Sync协议

Microsoft Exchange Active Sync协议,简称EAS,分为folderrsync(同步文件夹目录,即邮箱内有哪几个文件夹)和sync(每个文件夹内有哪些文档)两部分。

某网友总结的协议一次回话大致示范:

Client: synckey=0 //第一次key为0 Server: newsynckey=1235434 //第一次返回新key Client: synckey=1235434 //使用新key查询 Server: newsynckey=1647645,data=*****//第一次查询,得到新key和数据 Client: synckey=1647645 Server: newsynckey=5637535,data=null //第二次查询,无新消息 Client: synckey=5637535 Server: newsynckey=8654542, data=****//第三次查询,增量同步

大致交换简图如下:

如何获取新数据呢:

服务器端通知,客户端获取 客户端携带最新的SyncKey,发起数据请求 服务器端生成最新的SyncKey连同最新数据发送给客户端 基于版本号机制同步协议,可确保数据增量、有序传输 SyncKey,由服务器端序列号生成器生成,一旦有新消息产生,将会产生最新的SyncKey。类似于版本号

服务器端通知有状态更新,客户端主动获取自从上次更新之后有变动的状态数据,增量式,顺序式。

微信的协议

为保证稳定,微信用了长链接和短链接相结合,微信划分了http模式(short链接)和 tcp 模式(long […]

MQTT协议的学习

MQTT简介

MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)是IBM开发的一个即时通讯协议。它的设计思想是轻巧、开放、简单、规范,因此易于实现。这些特点使得它对很多场景来说都是很好的选择,包括受限的环境如机器与机器的通信(M2M)以及物联网环境(IoT),这些场景要求很小的代码封装或者网络带宽非常昂贵。

MQTT协议是为大量计算能力有限,且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议,它具有以下主要的几项特性:

使用发布(Publish)/订阅/(Subscribe)消息模式,提供一对多的消息发布,解除应用程序耦合 对负载内容屏蔽的消息传输 使用TCP/IP提供网络连接 有三种消息发布服务质量 “至多一次”,消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况,环境传感器数据,丢失一次读记录无所谓,因为不久后还会有第二次发送。 “至少一次”,确保消息到达,但消息重复可能会发生。 “只有一次”,确保消息到达一次。这一级别可用于如下情况,在计费系统中,消息重复或丢失会导致不正确的结果。 小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量 使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制

简单的说MQTT协议是一个轻量级的即时通讯协议。因为它被运用在一些硬件和网络不太好的环境,所以它对设备的要求不会太高,以适应艰难的环境。同时要保证信息传递的质量,所以有三种发布质量模式(QoS)

它原生条件下是基于TCP/IP的的应用层协议屏蔽了消息传输的具体数据交互格式。也就是不用关心底层是怎么传输的,数据用的是什么格式来传输的在物联网领域(IoT,Internet of Things)未来会有大发展。

MQTT的发展背景

物联网中的数据传输会面临很多问题,比如在网络不稳定的情况下,如果保证数据的传输没有问题,如何保证数据不被重复发送,连接断开后如何进行重连。总体来说,物联网的接入会面临以下几个方面的挑战:

设备、传感器。物联网接入对终端采集和控制设备要求高,且终端的改造以及网络费用成本也比较高。另外,其对终端的能耗要求也比较高。 网络。现有的网络传输贷款参差不齐,传输网络不稳定。 服务器。高并发情况下,多客户端的接入能力以及消息处理能力。

MQTT的发展历史

在物联网中,开源和开放标准是基本的要素。MQTT的发展历史大致如下:

1999年,IBM和合作伙伴共同发明了MQTT协议。 2004年,org开放了论坛,供大家广泛参与。 2011年,IBM建立了Eclipse开源项目Paho,并贡献了代码。Eclipse Paho是MQTT的Java实现版本。 2013年,OASIS MQTT技术规范委员会成立。 2014年,MQTT正式成为推荐的物联网传输协议标准。

MQTT协议

目前MQTT大家都用在了手机推送,如FacebookMessenger,因为小巧,省电,协议开销小和能高效的向一和多个接收者传递信息,故适用于移动应用设备上。那么轻巧在哪里呢,协议简单,最小的头部只需2个字节。相对于XMPP,MQTT更加轻量级,并且占用用户很少的带宽。整体上协议可拆分为:固定头部+可变头部+消息体

第一个byte 用于说明消息体的信息. 第二个byte 用于传输我们需要传输的数据. 更多详情请看协议 msg-format 部分

MessageType(0和15保留,共占4个字节)

“MQTT_CONNECT”=>1,//请求连接 “MQTT_CONNACK”=>2,//请求应答 […]

WhatsApp通信协议的学习

WhatsApp以190亿美元的价格出售给了Facebook,特别引入注意的是该服务4.5亿活跃用户的公司只有32个工程师,以下内容是HighScalability创始人Tod Hoff分析的WhatsApp的高可靠架构。

信息源

需要注意的是, WhatsApp的整体架构并未公开,这里仅仅是从不同信息源中获取不同的片段。Rick Reed的讲座主要分享了使用Erlang实现单服务器200万连接数,虽然很有价值,但是并不是整个应用架构。

Rick Reed:扩展到数百万并发连接数(2012, PPT) Rick Reed:Erlang Factory(访谈) Eugene Fooksman:WhatsApp的Erlang使用(访谈) DLD14:关于WhatsApp(Jan Koum和David Rowan) Yowsup以前是WhatsApp的一个开源API,但是由于弃用了DMCA当下已不可用,但是同样可以说明WhatsApp的一些内部工作机制。

相关文章中列出的一些信息。

一、统计

这些统计是当下系统的一些数据,更多针对数据存储、消息、meta-clustering以及新加入的BEAM/OTP补丁。

5亿的活跃用户,并且是史上最快达到这个数字的公司 32个工程师,平均每人支撑1400万活跃用户 每天收发跨7个平台的500亿消息 平均每天注册用户过百万 0广告开销 800万投资 数百个节点 8000+核心 数百TB内存 每秒Erlang消息超过7000万 在2011年,WhatsApp单服务器取得100万个tcp会话,同时还有内存和CPU剩余。在2012年,tcp会话发展到了200万。2013年WhatsApp 发表tweet声明,70亿消息入站,110亿消息出战,即每天处理180亿消息,伟大的2013,2014年每天有 190 亿消息进站/ 400亿消息出站 6 亿图片,2 亿音频, 1 亿视频 峰值并发连接为47 亿 消息峰值为每秒2 万进站/71.2 万出站 节日期间流量更加惊人

二、平台

后端

Erlang(经过了自己的改造) FreeBSD 9.2 Yaws、lighttpd PHP BEAM定制补丁(BEAM类似于Java的JVM,但适用于Erlang) 数据库使用的是Mnesia ejabberd […]

环信即时通讯的技术要点学习

即时通讯(IM)功能是APP的重要功能之一,而开发好移动IM却绝非易事。通常来说,IM技术选型至少要解决以下问题:

协议选型 IM服务器选型 对协议和服务器做相应修改,通常来说直接拿个标准协议和开源服务器是一定不能用到生产环境的 保证消息到达率,绝不丢消息

以上4点搞定后基本就有了一个可用的IM平台上。想更上一层楼,可以对电量和流量等做进一步优化,或者研究怎样支持百万级以上的用户。

协议选型

常用做IM的协议:

IM服务器选型

常见的开源IM服务器

标准协议及IM服务器的改进

XMPP协议的问题及改进

登陆握手部分的改进:XMPPQuickStart (XEP0305) 心跳改进:Xmpp Ping/Pong (XEP0199)40+字节 -> 单向 whitespace ping 4字节 文件传输:Xmpp协议的文件传输是点对点,需要改成用http上传的server,语音视频压缩后上传 Presence:对移动互联网场景,不转发是否在线(永远在线) Muc聊天室:Muc是群聊天协议,要改进成移动社交app中的群组,发送消息时发送给群里的所有用户,而不是只发“在线”用户,disable presence

Openfire源码级别改进

发送消息回执:java 里维护一个发送消息的队列,收到client端的回执,把消息从队列移除,在close()函数里,把未收到确认的消息存到offline msg里 离线通知插件:实现一个offline notification plugin。msgListener = new NotificationListener();OfflineMessageStrategy.addListener(msgListener); Muc changes:java send(Packet),如果是Presence不需要broadcast.Broadcast()不是只发给在线用户,改为发送给所有用户 性能,状态数据和无线状态数据分离:不要使用内置数据库,Vcard 可以用 memorycache 提高访问速度,好友列表加载到内存 redis,提高效率(可以考虑用一台单独的server)

移动网络环境下的优化

长链接的维护:Android 平台,维护client到server的长链接,添加网络监听,service自动重启。iOS平台直接用APNS即可 心跳包 GGSN:维护移动网 GGSN 路由 消息回执处理(ack):移动网络有可能丢包,发送,接收需要加入回执机制 语音图片的收发优化:大文件分拆为多个数据包,每个包 […]

段子集(zz)

发信人: TomCleverley (沉舟侧畔), 信区: Joke标 题: 段子集(zz)发信站: 水木社区 (Mon Dec 28 20:29:20 2015), 站内

"为什么我的jj这么小"我十分苦恼的说 "因为你没有切换大写啊,你看我的JJ就这么大"单纯的妹子

晚上心血来潮想和老公洗个鸳鸯浴,我脱光光泡进了浴缸,老公却傻站着不动,我说,“赶快进来呀”,老公无奈地说,“这还有我的位置吗”!

有个行人在扁担上挂着一只茶壶,茶壶突然坠地而碎。可他头也不回地继续朝前走。别人见了忙喊,“喂,茶壶碎了!”那人淡淡的答道:“既然碎了,回头看又有何用?”众人听了大怒,围上去一顿暴打。一边打一边骂:“随地乱扔垃圾,还装什么b?…

qq群是个神奇的东西:居然有跟腱断裂群,因为这东西断裂恢复阶段容易再次断裂,所以他们群里还分一断二断三断四断等等荣誉等级,目前最高的是4断。昨天和一个2断一起滑雪泡温泉,他就斩钉截铁的说刘翔那就不可能是跟腱断裂。这是他们群几断高手们集体判断。

最新骗局–遇到身材特别好的美女搭讪一定小心,她会说自己父亲是高官顺带经商,待你上钩之后,女子会过户一套别墅和一辆豪车到你名下,再给你一大笔钱,然后要求和你过夜,你逐渐陷入骗局,最后娶了女子,你就得和她过日子!然后,你要啥有啥不用上班工作,整天玩物丧志成了一个社会的废人!!!!

 如果女友突然告诉你,她去测艾滋病毒测出来呈阳性,你该怎么办? “ 假装很震惊。”

康熙持国最久,手段最硬,是有清一代的伟大领袖;雍正虽然表面低调,但出手却狠,不怕杀人,算是雍乾盛世的设计师;接下来的乾隆坐享其成,有事没事写几首歪诗,搞点桃色花边新闻出来,再接下来的嘉庆就没多大起色,在位途中最让人记得起来的大事就是把和珅给搬倒了。接下来道光最出名的,就是节约……

八戒说:“师兄,你快去医院看看吧,听说医院专门为你开了一个科室。”悟空:“哦?什么科室?” “二逼猴科!”

在公交车上,一位民工大哥,在司机后方的位置,我在大哥后面坐 突然大哥手机铃声响了。 先是警笛声,后面响起: “前面的公交车靠边,靠边,后面有车队。”蛋疼的是,司机大叔,真的靠边了。。。

华人自尊心四大法宝:“那里黑人是不是很多啊,小心点”;“印度人的英语太无语了”;“傻逼洋人加减乘除还要计算器”;“棒子好看肯定是整容的啊”。

诚恳地劝戒大家大雾天轻易不要出门,太tm吓人了。我当时正在公路小心翼翼慢慢地骑车,地方很荒凉,突然感觉很沉重,车胎好像瘪

聊聊刷题

在之前的文章中我讲述了我在面试上的经历和看法,而对于软件行业的面试很多都要求被面试者解决一些编程上的问题。这类面试有很多名字:算法题(Algorithm Question)、编程题(Programming Problem)、考代码(Coding Interview)等等,但基本形式都是给出一道问题的描述和目的,要求写出程序能够接受相应的参数然后完成目标需求得到最终结果。

大部分常见的这类面试问题都被大家总结在了网上,可以直接搜索找到,或者在一些论坛的特定板块(比如未名空间的待字闺中,一亩三分地的面经)里见到讨论,甚至形成了在线测试网站(比如LeetCode、LintCode)直接验证程序的正确性。

由于面试题目的公开性,造就了软件行业特殊的面试准备过程:刷题。很多朋友也会问我:“出去面试还刷题吗?”准确地讲,我刷过算法题目,也经常后悔没有早在还在学校里时就开始刷题,那样就能更早地进入心仪的公司。但现在出去面试前基本都还是忙着正常的工作,不会专门去练习题目。

刷题的目的是理解算法和数据结构

好比读书的时候每次老师教授了新的知识总是会布置习题,完成那些作业可能会让我们在考试中碰到原题而拿到高分,但正真的作用是帮助我们理解和消化知识。从简单的理解:“程序=算法+数据结构”,要写好程序就必须去熟悉算法和数据结构,刷题应该是完成这样的作用。如果题目做不出来,就说明连最基本写程序的能力都没有,自然很难得到公司的青睐。

我常常幻想如果我高考没有失常,能进入更好的学校学习计算机知识,甚至参加ACM小组,得到老师在算法上更好的点拨指导,也因为要参加计算机竞赛,我也会练习更多的题目,现在就不需要刷题了。但现实是在我就读的大学里,算法只是一门选修课,我也没有参加过任何计算机竞赛。但联想高中数学竞赛的培训过程,老师肯定会分类进行知识传授和练习。所以刷题也一样要分类进行强化训练。

LeetCode虽然是最火的题库,但是在我刷题的时候它只是简单的罗列一百多道题目(可参加我不完全的题解列表),所以当时我更倾向去做UVa上的题目。那上边有上千道题目,肯定是不可能做完的,但是有比较好的分类,可以专门的加强某一方面基础知识的不足。

一开始我连最简单的二分查找算法都写不好,但是在反复练习之后,我也能总结出二分法的实现,并汇总一些变形题目到博客里。刚毕业那会找工作,好多次面试都挂在了二叉树上,后来做遍各类遍历算法,总结了不同的实现方式,就不再担心关于树的操作。动态规划在我看来是面试时会碰到最难的问题,后来我发现这类问题的关键在于找到类似于数学中的“递归公式”,这样就可以找到递归的实现,之后利用空间来存放中间值来减少时间复杂度。

算法设计和分析比实现更重要

对于一道编程问题,选用不同的数据结构和算法会得到不同的实现方式,比如“最长公共子串”。所以光能够写出问题的实现还不够,还需要知道怎么针对问题设计算法,然后分析算法的复杂度来比较不同实现直接的优缺点。因此刷题之外,还需要记住每种算法实现的时间复杂度和空间复杂度。最常用的是Big O notation。

本文不是介绍算法的文章,但是我想分享我是如何反过来利用“复杂度”理论来帮助我在面试中解决一些我没练到我的题目。

首先大家都知道算法主要注意时间复杂度,而优劣排序也很直接:O(1), O(log n), O(n), O(n log n), O(n2), O(nk), O(2n)。然后我们需要知道每种复杂度对应的有哪些算法和数据类型:O(1)是Hash,还有其他简单的运算;O(log n)是二分查找算法;O(n)是一次遍历,可以是多次循环;O(n log n)是排序算法和平衡二叉搜索树;O(n2)和O(nk)是多层嵌套循环;O(2n)就是没有优化的DP了。

做题时如果已经知道了最优解,那就直接在面试官面前来个表演时间就好。如果没见过,那就先想暴力算法怎么解,然后跟面试官讲思路,寻问是否合理。如果对方说能不能找到更好的?那就按复杂度优劣往下套,比如暴力用了O(n2),那看看排个序会不会好点,或者建个树存储一下,可不可以落到O(n log n)。要是面试官说还能再更好,那很多时候就是考虑用Hash了。如果某个问题关于的一个有序的数组,那就可以考虑二分查找算法将复杂度降低到。最简单的例子就是“在一组数里找出两个数,满足它们的和与指定目标相同”。

面试是一个可以互相交流的过程,所以不用闷头写答案,时而不时的向面试官寻求提示和帮助也是体现解决问题的能力和方式。有时候问题的最优解是十分讨巧的方式,那只能心理说个脏话,而那种问题面试官肯定不是在期待最优解。而对于某些问题实在答不上来,那只能想想考的是什么算法和数据结构,然后回去继续刷题了。

体现能力的不是会做什么而是做过什么

工作以后,我感觉Onsite时4-5轮面试全考算法的面试已经很少的,更多的考察系统设计,已经询问过往工作经历。面得算法也都比较基础,通常复杂度都在O(n)。任何考察动态规划的面试题,我个人都觉得是在耍流氓,因为通常工作中也很少用到。但因为有针对联系过,我也会惧怕,好几次都坦诚说题目我做过,面试官就直接略过到一下题。

当题目刷得越多,越觉得题目刷不完;工作时间越长,就越感觉面试问的算法工作中都不用实现。因为标准库都有,而且它们经历过数代的检验和测试,远比自己写的实现要更可靠,所以在工作中,我常常被别人要求删掉自己的实现直接用库方法。对有工作经验的获选人的能力考察不是看会不会做题,而更看重用没用过某个库或框架。对于系统设计的问题,其实也更多来自都不同框架和系统的阅读和理解,还有对设计模式的学习和分析,而不仅仅只是算法和数据结构。

在工作中写得代码除了考虑是否能解决指定问题,还要考虑可读性、维护性、扩展性、测试性等等。但是刷题时,肯本不会考虑这些方面,因为代码只有自己看只针对当前一个问题。如果是限时的算法比赛,为了提高书写速度,可读性就更加惨不忍睹了。至于测试,我一直是帮在线测试的运行过程和结果当做测试。

在线测试题的问题总是非常明确要做什么,就好像物理课里的“理想环境”。但现实工作的问题存在更多的模糊性,需要通过分析和交流来去发现真正的需求,而这些是刷题所不能提高的。而且测试问题的数据规模只要真正参与到了项目中,经历了这样的过程才能在面试中,对于面试官类似“你觉得最具挑战性的项目是什么”娓娓道来。

提高运行效率的方法除了变更不同的算法和数据结构,其实还有终极奥义,那就是“多线程(Multithreading)”。如果线程安全就可以把操作分配到多个线程上并行使得效率大大增加,但刷题练习到的都是基于单线程的编程。但是某个实现是否满足多线程,以及如何做好线程安全又是一门学问。

所以刷题只能表示某道题目会做,但是真正能体现胜任工作的能力还需要在正式的工作中提升。这可能也是为什么对于没有工作经验的应届生,面试只考察算法。

 

要想在软件行业获得份理想的工作,刷题还是不可缺少的过程,但是刷题并不是工作唯一的要求。只不过算法题的考察决定着是否胜任软件行业的工作,能拿到什么的package以及title,还看其他的能力。在工作之余,做点小项目或许比刷题更有意义。

[…]

真事

发信人: Orel (Orel), 信区: Joke标 题: 真事发信站: 水木社区 (Sat Dec 26 15:35:14 2015), 站内

老丈人开一小广告店,有段时间一个小工经常来干活,大家都叫“小宋”。和他混熟了后,有一天不经意看到他的身份证件,全名叫“宋徽宗”,哇塞!看到后很是惶恐,差点下跪~ 大家嘻哈几句,他很从容,说他还有个弟弟,名叫“宋高宗”~—

※ 来源:·水木社区 http://m.newsmth.net·[FROM: 59.151.95.*]

使用JavaScript脚本配合Steam inventory helper扩展快速出售Steam上的多余卡片

Steam一年一度折扣力度最大的圣诞节冬季特卖活动正在展开, 在像例行事项一般将愿望单里的游戏尽数购买后才发现钱包空空的后悔之时, 各位可以考虑在这个季节将自己库存的卡片出售一下了.

对博主这种喜+1到2000个游戏的Steam用户来说, 出售卡片一直是个漫长又痛苦的差事, 一方面是由于游戏太多, 挂出的卡片规模太庞大(比如, 我的卡片数量常年在1000~2500张左右浮动), 另一方面是没有好的出售多余卡片的方法(也许是我没有发现), 像是那些一个徽章所需的6种卡片里只收集了1种或是2种的基本不会去合成的卡片, 留着也没有什么用处.

平日里在Steam inventory helper扩展的帮助下, 我可以同时选中多张卡片然后一并出售, 但这并没有解决我卡片数量巨大带来的问题: 前天我试图卖掉我多余的卡片, 可1个小时过去了, 我似乎连多余卡片的一半都还没能卖掉, 卡片实在是太多了!

人工产生的效率在已经形成规模的数据面前未免过于渺小, 于是当天我花了点时间编写出了steam-surplus-card-sells-helper. 当天晚上, 用它选中并出售了347张多余的卡片, 第二天起床发现钱包已经进账100多元, 还算不错, 今天在此把这段脚本分享给有需要的Steam用户.

这段脚本的原理是在徽章页面读取到所有徽章信息, 然后找到所有卡片数量低于合成要求一半的游戏, 再通过Steam inventory helper的批量选中库存物品的功能, 将卡片统一批量的卖出. 懂前端的朋友可以自行修改代码实现别的效果, 代码编写得匆忙, 质量不高还请见笑. 本来这个脚本是要弄成bookmarklet, 不过我试验了一下, 在Steam的网页上受Chrome的CSP影响, bookmarklet是不能用的, 所以还是改成手动运行代码的形式.

使用方法 准备步骤

首先确保你安装了Steam inventory helper扩展, 这个脚本需要配合它使用.

然后进入这个页面: http://blackglory.github.io/steam-surplus-card-sells-helper/main.js 全选并复制其中的代码.

提取你的徽章信息

在浏览器里登录Steam, 打开你的徽章页面.

按F12打开浏览器的开发者工具, 往Console里粘贴代码, […]

为啥火鸡叫土耳其

发信人: MunirHaddadi (巭孬嫑夯昆勥茓), 信区: Joke标 题: 为啥火鸡叫土耳其发信站: 水木社区 (Sun Dec 20 18:29:17 2015), 站内

上次走访土耳其专门问土耳其学者这个问题,为啥火鸡叫土耳其。他答:因为最早到西方的火鸡就是从土耳其来的。那么在土耳其,火鸡叫啥呢?答:叫印度。因为土耳其人认为最早到土耳其的火鸡是印度来的。

zz from 宋鸿兵微博—

“The credit to them, the better team won and there’s nothing we can do about that now.” (On defeat at the hands of Barca, Champions League final, 2009)

※ 来源:·水木社区 newsmth.net·[FROM: 125.33.61.*]

Category

Archives