资源推送

资源推送（精选10篇）

资源推送 篇1

随着国内外社交网络迅猛发展, 尤其像Facebook、Twitter、新浪微博用户的数量空前暴涨, 在如此庞大的社交网络中各个用户之间都能够直接或间接的连接成一个错综复杂的社会关系网络, 任何一个人都是置身于一个或者多个相似群落当中, 如此一来可以考虑将用户的社交关系结合到服务推荐技术中[1], 从而为每个用户提供有效的服务资源推荐。国内最大的社交网络平台新浪微博, 自2009年推出以来, 以迅猛的发展速度独占国内几大社交网络平台鳌头, 目前新浪微博注册用户已经超过5亿。在这样一个庞大的网络平台中, 每一个用户都可以根据其掌握的社交关系来给周围的圈子推荐自己喜欢资讯, 话题, 产品等等网络服务资源。然而, 如何利用社交网络分析, 通过构建社交关系网络来给可能感兴趣的用户推荐服务;并且不造成信息泛滥或乏味广告的尴尬局面, 是一项意义深远的研究。本文将试图通过分析新浪微博中的用户之间关系, 根据用户的好友分组与粉丝列表等数据来获取目标用户集合, 进而做服务推荐。

1 相关工作

目前常用服务推荐技术中, 主要分为三类[2]:基于内容推荐、协同过滤推荐、混合推荐 (结合前两种推荐技术) 。其中协同过滤推荐技术在目前推荐技术中的应用是比较成功、广泛的一种技术[3]。协同过滤推荐技术是在“当前用户喜欢其相似用户喜欢的项目”的这一假设的前提下, 通过对相似用户对某一项目的评价来预测当前目标用户的评价情况[4]。以上这几种推荐技术中都存在数据稀疏[5]和冷启动[6]的问题。传统的协同推荐技术中, 由于用户对项目评分数据的稀疏性, 仅把用户的相似度作为依据来选取推荐的目标用户, 这对推荐的精确性是难以保证的。针对这些问题国内外一些学者做出了相关研究, 黄创光等[7]提出了基于动态邻居的协同推荐技术。贾冬艳和张付志[8]提出了一种基于双重邻居选取策略的协同过滤推荐算法, 通过计算邻居的相似性和邻居用户之间信任度来进行对项目的协同过滤推荐。冯勇等[9]提出了一种基于社会网络分析的协同推荐方法的改进算法, 给社会网络中的人物关系 (如:家属, 亲人, 朋友, 同学等关系) 设定一个信任权值, 然后根据计算信任度来进行推荐。杨微[10]提出了基于社会网络社团发现的协同推荐方法, 通过网络用户进行社团划分来进行推荐。邢星[11]在社交网络个性化推荐方法研究中通过社交网络中的用户关系 (关注, 粉丝等关系) 分析和对用户兴趣的预测估算, 来获得目标用户的推荐列表。以上这几中方法对传统协同过滤推荐技术中存在的稀疏性问题都有非常好的改进, 并且通过社会网络关系的引进, 使得服务推荐的精确性有了一定的提高。社会网络分析 (social network analysis, SNA) 主要是研究社会网络中行动者之间的关系[10,12], 本文则侧重研究社交网络中用户好友分组 (如朋友, 同学, 同事等组别) 之间的相似关系和信任关系, 将用户之间的相似关系和信任关系结合起来, 预测目标用户对须要被推荐的项目评分, 对比各个用户对项目的预测评分, 获得给出评分较高的那一部分用户列表, 最后将这些用户作为推荐该项目的目标用户。

2 面向社交网络的服务推送方法

2.1 相关定义

社交网络中任意一个人用户, 以自己为中心, 都有m个用户与之构成一个关系网络。存在这样一个与当前用户联系的用户集合U={u1, u2, …, um}, 同时, 当前用户想要给其他用户推荐的n个项目集合I={i1, i2, …, in}。

定义1用户关系网络

本文构建的是以当前用户为中心点, 以当前用户的朋友列表中的每个用户为终点的一个关系网络。可以用一个二元组来表示UN= (U, E) , 其中U表示与当前用户朋友列表中的用户集合, E表示当前用户与其连接的每个用户的之间关系的关系集合。

定义2用户间相似关系

在用户关系网络中, 根据用户对项目的评分、用户标签等可以获得潜在具有相似兴趣的用户分组。本文将每一个用户之间相似关系权重作为相似关系, 即US (ui, uj) =Sim (ui, uj) , 其中ui, uj分别表示用户ui, 用户uj。

定义3用户间信任关系

在用户关系网络中, 当前用户的与其相联系的用户集合中的每个用户都有其对应的关系, 这些关系从其好友列表中获取, 如:家属, 亲人, 朋友, 同学等关系, 本文将两个用户之间的关系定义一个信任度数值u (0<u<1) , 即两个用户间信任关系, T (ui, uj, relation) , 其中ui, uj分别表示两个用户, relation为两个用户的关系类别。

定义4目标用户集

根据用户相似关系和信任关系综合计算得出每个用户对项目的预计评分, 从而获得给出项目评分大于某一阈值的目标用户集合, 记为Ut。

2.2 用户关系计算

2.2.1 用户相似关系计算

在推荐系统中, 用户相似性的计算对推荐系统的性能起到至关重要的作用。通常相似性计算有余弦相似性、修正余弦相似性以及Person系数相似性这三中方法[13]。由于在推荐系统中, 用户对项目评分的宽严尺寸不一, 导致对同一项目的评分的差异性较大, 如果采用余弦相似性来计算, 很可能导致计算结果与显示差别较大。Person系数相似性计算, 一方面要考虑用户样本的相关系数, 另一方面, 还需考虑两个变量的总体分布是否为正态分布或接近正态分单峰分布, 并且两个变量的标准差都不能为零。修正余弦相似性能够很好的克服以上的问题, 所以本文采用修正余弦相似性来计算两个用户之间的相似性, 见式 (1) 。

式 (1) 中, rum, i, run, i分别表示用户um和用户un对项目i的评分, rum, run为用户um和用户un的平均打分。

2.2.2 用户信任关系计算

在传统的推荐系统中, 往往没有把用户的信任关系考虑到推荐过程中, 然而现实生活中, 无论信任关系对用户的消费意愿、接收心态等都有着非常大的影响, 同样在推荐系统中, 信任关系也对服务推送的精确性、可靠性都有很大影响。在社交平台中用户与其他用户之间存在现实关系, 如家人亲属、朋友、同学、同事等等。本文将每一种关系规定一个信任值, 以社交网络中常见关系列表中的家人亲属 (family) 、朋友 (friend) 、同学 (schoolmate) 、同事 (colleague) 、关注或被关注 (follower) 为关系样本, 每一种关系对应一个信任量度。T (ui, uj, family) =1, T (ui, uj, friend) =0.8, T (ui, uj, schoolmate) =0.6, T (ui, uj, colleague) =0.4, T (ui, uj, follower) =0.2。

2.3 目标用户项目评分计算

传统的协同推荐技术中, 在计算目标用户对项目的预计评分时, 通常采用式 (2) 计算。

式 (2) 中, ru, i为目标用户u对项目i的预测评分, 珋ru为用户u的平均评分, rv, i为用户v对项目i的评分, 珋rv为用户v的平均评分。这个算法中, 只将用户的相似性考虑其中, 当推荐系统刚开始投入运营时, 由于用户对项目的评分数据非常稀疏, 这样就会导致整个系统在计算目标用户对某一项目的评分会出现很大的偏差, 而且整个系统将长时间处于冷启动状态。本文将采用社交网络中人员关系构建一个用户关系网络, 结合用户间相似性和用户间信任度来对传统推荐系统中预测目标用户对项目的评分算法加以改进。计算公式 (3) 如下。

式 (3) 中, ru, i为目标用户u对项目i的预测评分, 珋ru为用户u的平均评分, rv, i为用户v对项目i的评分, 珋rv为用户v的平均评分。tu, v为用户u, v之间的信任度, θ为用户相似关系与用户信任关系的平衡因子。使用该算法, 在系统刚开始投入运营时, 可以将平衡因子尽量小, 系统就会根据用户之间的信任关系来计算目标用户的预测评分。随着系统用户评分数据的逐渐丰富, 逐步调控平衡因子θ, 最终趋于0.5, 推荐系统就能有效地综合用户相似关系和信任关系来作智能推荐。如此一来, 传统系推荐技术中的冷启动问题和推荐性能不高的问题就能得以解决, 同时在推荐的可靠性, 精确性方面都会得到有效的提升。

3 实验过程与结果分析

本文实验中, 将用户对项目的打分与用户之间的关系相结合, 实验数据参考以下两个平台的数据来做模拟实验。

(1) Movie Lens网站 (http://movielens.umn.edu) 是一家大型的电影评分网站, 用户可以对上面的电影进行打分推荐, 评分范围1~5分, 分别表示不喜欢, 一般, 中等, 良好, 非常喜欢。本文将参考这种评分方式来对项目进行评分。

(2) 实验中用户关系的数据来自新浪微博, 新浪微博开放平台 (http://open.weibo.com) 为开发者提供了大量的数据访问接口, 可以从中获取登录用户的关系列表, 用户标签, 实时微博等等数据, 本文主要采用用户的关系列表数据。

3.1 实验过程

通过调用关系接口列表和好友分组接口, 获得当前授权登录用户的关系用户。为了更清晰的表述本文思路, 只抽取部分用户来构建一个当前登录用户的关系网络图, 如图1所示。

图1中每条边都标明了两个用户之间的关系以及相似性和信任度, 相似性根据用户的收藏列表和用户点击项目以及共同评分项目来计算, 具体计算采用式 (1) , 信任度根据用户的关系分组列表来计算。然后根据上一节中改进的目标用户预测评分算法式 (3) 来计算每个用户的预测评分, 选取评分大于某一阈值的所有用户作为目标用户, 从而获得推荐目标用户集合Ut。

实验过程中, 当登录用户发布一款应用或者一部电影、一个话题的同时给出自己的客观评分, 然后提交给推荐系统, 最后推荐系统将根据当前登录用户A与其的关系列表中的用户的相似关系和信任关系来智能推荐A发布的应用。推荐系统的整个推荐过程如图2所示。

实验中将本文提出的面向社交网络的推荐方法和传统的协同过滤推荐方法进行比较。实验过程中, 采用多用户访问来进行实验测试。为了能够体现出实验结果的相互可比性, 控制每一组实验中用户的关系列表中人数呈递增形式。本文主要采用平均绝对偏差 (normalized mean absolute error, MAE) 和覆盖率来对推荐质量予以评价。平均绝对误差值越小, 算法的准确性更高;覆盖率的值越大, 其预测结果范围就越大。平均绝对误差计算式 (4) 如下。

式 (4) 中, P为预测评分集合, pi∈P, Q为用户实际评分集合, qi∈Q。

覆盖率计算式 (5) 如下。

式 (5) 中, Np为本文算法中的实际预测到的用户数, N为需要预测的用户总数。

3.2 结果分析

根据实验, 得到本文提出的面向社交网络的推荐方法与传统推荐的方法的比较结果。如图3所示。

由上图可以得出, 本文所提出的推荐方法, 绝对平均误差随着获得的目标用户集合的人数的增加而减小, 覆盖率随着目标用户集合人数的增加而增大。显然, 本文的所提出方法比传统的协同过滤推荐方法有更好的精确性, 可靠性。

4 结束语

本文分析社交网络中用户关系, 提出一种面向社交网络的服务推荐方法, 把用户相似关系和信任关系结合起来对传统的协同过滤推荐方法作出改进, 使得本文提出的方法在面向社交网络平台上的服务推荐技术有着更高的准确性和可靠性。由于传统的推荐方法主要依赖于用户对共同项目的评分来计算用户对新项目的预测评分, 这样一来就导致当推荐系统刚刚投入运营时, 由于没有共同评分项目的记录, 可能很长一段时间整个系统都处在冷启动状态。本文提出的改进方法中, 对新项目的预测评分并不完全依赖用户共同评分的项目, 当推荐系统刚开始投入运营时, 通过调控相似关系与信任关系之间的平衡因子θ, 来计算用户对新项目的预测评分, 如此一来, 同时针对服务推荐的冷启动问题也能够给出有效地解决。随着社交网络的蓬勃发展, 基于社交网络的推荐系统势必有着非常广泛的应用研究价值。

摘要：传统的基于协同过滤推荐、内容推荐等技术在资源服务推荐中虽然得到了广泛地应用, 但这些方法针对矩阵稀疏、冷启动等问题, 在一定程度上还是未能有效地解决, 以致推荐效果不是很理想。根据用户社交网络中关系, 把用户之间的相似关系和信任因关系作为构建服务推荐目标用户列表的计算因子, 从而对网络资源服务向目标用户做出有效而精确地推荐。通过实验分析, 这种方法在面向社交网络平台上的资源服务推荐有着明显的优越性。

关键词：社交网络,服务推送,推荐方法,相似关系,信任关系

内容推送器 篇2

《未来是湿的》这本书有很多论断是相当精辟的，它基本上描绘了人们在无名无利的前提下却依然在拼命制造信息的逻辑，而且还造得不错，比如维基百科。但从高度上讲，即便是《未来是湿的》（更不用谈《认知盈余》了）谈的都不是互联网的大问题。因为对于网络而言，信息生产，永远不是第一位的问题。

让我们稍许来回顾一下历史。互联网从商用以来，历经门户、搜索、社交三代。门户走的路子是所谓“受过训练的编辑”推送（push）信息给你看，搜索则让你可以借助关键词拉取（pull）信息，在社交网络上，你获取信息的方式是：追随你的朋友。这三代杀手级应用，其实根子上要解决的问题是：你是怎么接触信息的？换言之，这三代商业上获得巨大成功的应用，说白了，就是三种“内容推送器”。

对于数字世界来说，内容生产从来不是什么难事，因为人类内心深处是有表达欲望的。但是，如果只是做好了内容生产而忽视信息接触，那就会成为一场灾难：最典型的例子莫过于“博客”。

就个人使用而言，博客是一种非常全面的内容生产工具，可以嵌入你想要的任何一种信息形式，从文字到图片或是视频，也可以在一篇文章中布满超链接。但博客的缺点在于：它的架构并不利于信息接触。一个博客主不知道什么时候会写一篇新的博客，于是ta的读者便不知道什么时候去看ta的博客才是合适的时间——虽然RSS阅读器在帮助解决这个问题，但这个应用委实太过小众了。老实讲一句，和一个网络小白讲明白RSS是什么东西，都得花不少时间。

早些年MSN有一个“小黄星”的功能，MSN列表上的好友名称后一旦出现这个小黄星，就意味着ta的空间更新了，这可以驱动人们去点击进行“信息接触”。但不知道为什么，微软扔掉了这个小黄星，当信息接触者（阅读者）少了以后，信息生产者的动力就开始下降。写了没人看？那我还不如去打开一个WORD编辑器算了。

现在我们来谈谈文头提到的这个网站——知乎，一个问答社区。知乎对《认知盈余》的热捧，几乎让我怀疑他们是把这本书当成自家网站融资扩大规模的理论依据了。但在我看来，知乎最要紧的问题不是鼓励信息生产，而是让人们去接触信息。最近他们搞了一个“寻找互联网思想者”的活动，一字排开网络十个大腕，马化腾的第一个问题就引来了极多的长篇大论的问答——可见信息制造对于当下的知乎而言，一点问题都没有。

我是知乎的重度使用者，我一点也不想掩饰我对这个网站的喜欢，但随着知乎的内容越来越多，后来还设计出类似频道性质的领域，现在要找到我想看的信息变得越来越费事。我倒是觉得，知乎的核心问题应该是这样的：如何让一个刚刚上知乎的人，迅速接触到ta想接触的信息；而不是这样的：如何让一个刚刚上知乎的人，迅速生产ta能生产的信息。从商业角度而言，前者更重要

在我看来，《新数字秩序的革命》这本书远比《认知盈余》更具有高度，因为它一直在探讨的问题是：在数字世界中，信息是如何被组织的——往下一步，就是如何被人接触的。在一个信息爆炸的时代，这样的问题，难道不是比如何加大信息供给来得更具实际意义么？

多年以前，人们一直在探讨下一个杀手级应用是什么？我倒是觉得，讨论这个问题至少对我而言，逻辑是很清楚的：从推送到抓取到跟随朋友，下一种会让极大规模的人群都接受的“接触信息”的方法是什么？

这个问题一旦有了答案，下一个杀手级应用，便呼之欲出。

最后必须说明一下，信息两个字，并不是专指某一篇文章，可以是任何东西，比如女朋友抱怨生日没有得到想要的礼物——这也是信息，对于当事人而言，是极其重要的信息。

资源推送 篇3

无论是传统教学还是网络教学, 学习个体都呈现出差异性, 这表现在智力水平、理解能力以及认知水平等方面, 因此千篇一律的教学方式和教学内容无法达到令人满意的教学效果。新课程改革也提出要注重学生发展的个体性与差异性, 重视开发学生个性潜能, 培养学生的创新思维与实践能力。目前, 许多网络资源库以展示和呈现资源为主, 其表现就是将课本或教案内容复制到网上, 没有体现出资源使用的个性化、教学特色和教学个性[1]。

根据文献研究和现有平台调研, 目前国内几乎没有师范生专业技能研习相关的成长案例库, 能提供个性化资源推送的更是寥寥无几。师范生是教师力量的后备军, 专业技能训练对其是十分必要的。师范生专业技能研习成长案例库平台将师范生在实习、见习、实训与竞赛等活动中积累的优质案例导入成长案例库, 为师范生提供了大量用于专业技能训练的优质资源。然而, 师范生如何在海量成长案例库中找到适合自己的个性化资源?本文通过对学习者学习偏好模型的分析, 构建了基于学习偏好的个性化推送机制, 可有效辅助研究性学习的开展, 并能进一步激发学习者的学习兴趣, 引导其深入探究相关知识。

1 个性化资源推送机制

个性资源推送最早出现在电子商务网站, 它将经过整理的资源转发至用户界面, 从而实现用户的多层次需求。如今, 个性资源推送机制不仅用于企业电子商务网站, 在资源型学习平台、数字图书馆系统、高校数字化校园建设、农业科技信息中也应用广泛。目前, 资源推送技术主要有以下几种:基于规则 (Rule-based) 的推荐技术、基于内容 (Content-based) 的推荐技术、基于协同过滤 (Collaborative filtering) 的推荐技术和混合式 (Hybrid) 推荐技术[2]。

综合目前网络教育资源库平台的个性化资源推送方式, 主要存在以下问题:

(1) 推送方式比较单一。热门资源推送和最新资源推送是比较常见的两种推送方式。热门资源点击率高, 虽然提高了优质资源使用率, 但其推送的资源未必是用户需要的;最新资源推送以数据库中资源更新的时间为依据, 将最新上传的资源推送给学习者, 同样也不一定满足用户需求, 资源质量也无法得到保证。

(2) 缺少对学习者数据和信息的科学分析, 无法掌握学习者的兴趣与需求, 对学习者兴趣偏好和需求的迁移不能及时作出应对。

2 基于学习者偏好的师范生资源库个性化推送机制

2.1 学习者偏好模型构建

在网络学习中, 学习者偏好主要表现在两方面:一是对学习内容选择的偏好, 二是对呈现学习内容的媒体类型选择的偏好。在学习内容选择偏好上, 假定呈现学习知识的媒体类型都是同一种, 例如, 学习者在研习高中数学相关知识时, 可分为几何模块和代数模块, 假如学习者习惯选择几何模块学习, 该模块下又分为椭圆、双曲线、抛物线等几个主题。学习者对每一个模块和主题都有一个偏好值, 这个偏好值可以选用-a-a (a>0) 的一个区间的数值来表示;在媒体类型选择偏好方面, 媒体类型可大致分为文本、图像、音频、视频4种, 如图1所示。因此, 在对相同内容知识的学习中, 如果学习者选择某种类型资源的次数远远超过选择其它类型资源的次数, 则认为该学习者对该类型的学习资源存在偏好。

2.2 学习者偏好确定

学习者学习偏好是系统为学习者提供个性化服务的重要依据。学习者偏好的获取具体可以通过两种方式:显式获取和隐式获取。显式获取又称为直接获取, 是指学习者在使用系统时会留下用户注册信息, 系统也会提供有关兴趣偏好的表单让学习者填写。但是由于需要用户主动填写, 通常用户会觉得繁琐, 不愿去填写或不会认真如实填写, 因此不能保证表单获取信息的准确性, 导致系统噪音;另一种是隐式获取, 隐式获取是通过Web日志挖掘分析用户历史信息, 挖掘学习者偏好, 如图2所示。

学习者在学习过程中, 会就某一知识点提出问题, 也会依据自己的兴趣和知识储备去解答别人提出的问题。同时, 学习者在系统中的检索、浏览记录等都在一定程度上反应出学习偏好。因此, 可以根据学习者在系统中的检索、浏览记录与提问来判断学习者对于知识的兴趣点。当学习者对同一个知识点的检索次数和提问次数达到N (N≥5) 次, 则认为学习者对该知识点存在偏好[3]。

当然, 学习者偏好不可能是一成不变的。随着学习者所学内容以及学习者知识储备的增加, 学习者偏好也会有一定程度的更新。好的个性化推送系统应能及时捕捉到学习者的偏好变化, 从而根据变化调整推送内容。学习者学习偏好的动态调整要综合考虑学习者之前的偏好与最近一段时间的个性化行为, 包括对知识点的访问浏览行为、与其他学习者或教师的交流行为、学习过程中的提问与回答行为等。

根据以上对学习者偏好模型的分析, 确定了师范生专业技能研习成长案例库的个性化推送机制———基于学习者偏好的个性化推送机制。

2.3 基于学习者偏好的师范生资源库个性化推送机制

学习者偏好模型是个性资源推送机制的核心和基础, 关系到个性资源推送服务的质量。个性资源推送中的学习者偏好模型不是对用户个体的一般性描述, 而是从有关用户兴趣和行为的信息中归纳出可计算的用户信息模型。

根据对个性资源推送机制和学习者偏好的了解, 现对师范生专业技能研习成长案例库平台中的个性资源推送机制进行分析。师范生在专业技能研习成长案例库平台的偏好可通过预定义范式和行为数据统计分析两种方式获得。

(1) 预定义范式分析, 即显式获取。是指通过采用一种符合普通意义上对“人”进行定义的一种范式来强制规范对人属性的描述[4]。如学习者的专业、研究方向、爱好、学习风格等, 是一种人为固定询问式的简单描述。学习者登陆系统后, 将填写系统提供的个人资料表单, 包括学习者专业、爱好、研究方向等, 通过这些描述可以从中获取到学习者部分偏好。

(2) 行为数据统计分析, 也称隐式获取。这是一种应用统计学上的数量分析法, 通过获取一定时间内用户单击的数量和分布来分析该用户的行为趋向[4]。比如, 对某学习者在系统中学习时检索、浏览、下载资源的类别和次数进行统计分析, 同时, 对学习者就某一主题发帖提问或回答其他学习者提出的问题中提取关键词, 通过学习者偏好模型的分析, 从中找出学习者兴趣偏好的行为规律等。

对于这两种分析方法, 基于前者实现的个性化资源推送是一种半智能化的资源推送, 而基于后者的行为统计分析则可被认为是完全智能化的资源推送。

当学习者的偏好迁移时, 系统动态调整的过程如下:系统记录最近一段时间内学习者提问或回答过的感兴趣的知识点, 以及检索、浏览、下载资源的内容和类型, 如果其学习偏好中的某些内容和类型已经不在这个范围内, 并且学习者对它的偏好程度小于他对所有感兴趣内容和类型的平均偏好程度, 则认为学习者已经对这部分知识点不感兴趣, 应当从学习者偏好中将其删除;同样, 如果一段时间内, 学习者的个性化行为所涉及到的某个内容, 学习者对其偏好程度大于他对所有感兴趣的内容和类型的平均偏好程度, 则应将该内容或该内容对应的类型添加到该学习者偏好中。

师范生专业技能研习成长案例库平台获取到师范生的偏好后, 在资源库的资源里根据资源分类和资源属性的描述, 提取出符合该学习者的资源, 推送给学习者进行针对性的学习。具体过程如图3所示。

例如, 某师范生在使用该平台过程中, 主要想提高教学设计方面的技能, 在这段时间内该学习者检索、下载、浏览、提问该类型资源的次数则会比较多。当学习者学习一段时间后, 教学设计方面的技能有所提高, 对教学设计类型的资源关注度降低, 转而学习课件制作方面的技能, 如果该学习者对教学设计资源的偏好程度小于他对所有感兴趣内容和类型的平均偏好程度, 则可以将教学设计这一部分内容从该学习者偏好中删除, 并将课件制作添加到其偏好中, 同时推送相关资源给该学习者。

3 结语

本文在构建师范生专业技能研习成长案例库的基础上, 针对师范生作为未来教师的特点, 将师范生在实习、见习、实训与竞赛中积累的优质案例导入成长案例库, 采用相关推送和基于学习者偏好的个性化推送方式, 为师范生更好地获取个性资源提供了条件, 极大地提高了师范生的专业技能, 有助于教师教育改革实现新的突破。

摘要：网络上关于师范生专业技能训练的资源数量巨大, 师范生如何在海量资源中快速准确地找到所需资源, 提高个人专业技能, 科学、有效的个性化推送机制尤为重要。为了实现为每一位师范生量身打造一套最适用的资源, 结合师范生专业技能研习成长案例库平台, 从学习者偏好的角度进行了分析。

关键词：个性化推送,师范生,学习者偏好

参考文献

[1]刘珍芳.高校专业网络资源库建设探析[J].电化教育研究, 2007 (5) :62-65.

[2]方琦.中小学网络学习平台个性化推送系统的研究与设计[D].杭州:浙江工业大学, 2013.

[3]赵海燕, 吴长勤.E-learning环境下基于学习者偏好的高校精品课程研究[J].沈阳工程学院学报, 2012, 8 (3) :419-420.

玩转Kindle 无线推送 篇4

Kindle 推送就是亚马逊提供的一个“Kindle个人文档服务”，我们只需要一个亚马逊账号，就可以通过以发送电子邮件附件的方式，免费将 Kindle 所支持的文档或电子书推送到亚马逊提供的5GB个人文档云存储中，当云端接收到了你推送的文档，将会自动转换格式（比如你推送的是 txt 格式会转换成 azw 格式）并同步到与此账号绑定的 Kindle 设备中。

无线推送图书

传统的邮箱推送

传统的邮箱推送与通过USB 连接的方式将文档或电子书拷贝到Kindle具有很大的差异性与便利性。直白地说，只要你使用同一账号绑定的Kindle设备都能很方便地从云端获取推送的图书。当然了，亚马逊对推送文件的格式有着严格的要求，除了Kindle默认支持的文档格式外（mobi、azw、PDF），还可以支持Word、TXT、HTML以及常见的图片格式。为了方便我们一次性上传多个文件，亚马逊的个人文档转换服务还支持 ZIP 压缩文件格式，系统会自动解压将文件转换为Kindle格式，然后存储在图书馆中。

在浏览器进入亚马逊站点并登录绑定Kindle设备的亚马逊账号，点击界面左上角的导航键，依次展开“浏览全部分类/Kindle 电子书阅读器”，找到“管理内容和设备”这个分类（如图1），点击“管理我的内容和设备”进入“管理我的内容和设备”页面，然后再点击“我的设备”选项卡，在设备列表选中绑定的Kindle 设备（如图2）。这时界面下方的电子邮件地址就是接收推送文档的目标邮箱，将其记录下来或是添加在常用邮箱的常用联系人中，接下来我们就可以通过常用邮箱向推送的目标邮箱发送电子书了。

为防止恶意内容推送，亚马逊的个人文档推送机制只接收受信任的电子邮箱地址，所以需要在“设置”页面底部找到“已认可的发件人电子邮箱列表”这一项，点击“添加认可的电子邮箱”把常用邮箱地址添加至信任列表中（如图3）。

登录添加至信任列表中的邮箱，新建一封邮件，接收推送文档的目标邮箱设置为收件人，主题与内容可以留白（如需将电子书转换为Kindle支持的格式，在主题一栏中输入Convert即可），随后我们便可将需要推送的文档或是电子书添加至附件中，点击发送即可（注意不要使用超大附件发送文件，Kindle推送文件大小只有50MB）。

稍等片刻，你的 Kindle 就可以收到推送的内容了，如果推送失败云端会重新尝试向设备推送你上传的电子书，如果Kindle已连接WiFi，等了很久却还是没有收到推送内容，可先到亚马逊账户下的我的内容页面检查发送状态，如果发送的内容已经存在“个人文档”中，Kindle 却接收不到，可尝试重新连接 WiFi或重启设备（如图4）。

即推即收的客户端推送

当然了，Kindle并非只有传统的邮箱推送模式，为了用户更加方便地推送本地磁盘的书籍，亚马逊还推出了官方PC版《send to kindle》，只要我们在PC端安装了此工具，就不再需要登录邮箱上传附件推送书籍了。

第一次使用send to kindle时，系统会自动提示我们登录亚马逊账号，登录账号后，无需设置系统就会自动找到绑定亚马逊账号的Kindle设备，当我们选中需要推送的文档，点击“Send”后即可推送成功，当然文档格式的支持也与传统邮箱推送的一样（如图5）。

当然了，为了更加便利地推送，send to kindle还有浏览器插件版，现阶段只支持Google Chrome与firefox 。当我们通过插件市场下载并安装了send to kindle后，系统会提示重启浏览器，点击确定即可完成插件的安装。由于是首次使用，我们激活send to kindle后，点击推送工具栏中的“setting”，等页面跳转后输入亚马逊账号与密码绑定后（如图6），就可以推送网络上喜欢的文章或是博客了。

让Kindle变身稍后阅读

Kindle通过推送的方式能让我们获得多种可阅读资源，但是它对网络上的文章进行整理阅读的能力却是很低下，如果我们希望它拥有更为出色的方式来阅读网络文章，并且还能方便地阅读我们筛选的网络文章，那么我们就需要借助Kindle助手这个第三方应用。

Kindle助手的原理其实就是利用信任邮箱向Kindle设备发送内容，从而让Kindle设备变成稍后阅读。首先，我们需要将Kindle 助手的发送邮箱（zhushou@kindlezhushou.com）添加为受信任的电子邮箱（如图7）。打开手机中安装的Kindle助手，在设置页面中填写接收到推送的Kindle设备亚马逊账号（如图8），点击完成就完成所有的设置了。

此后，当我们收到RSS订阅的文章或是查看到有趣的文章想要用Kindle进行阅读时，那就可以点击分享并选择Kindle助手，虽然Kindle在文章的排版上略显生涩，不过并不影响我们阅读的热情。

资源推送 篇5

i Pazz Port Cast体积小巧便携, 使用方法简单。支持DLAN、Airplay协议, 无需在移动终端安装任何软件;集成Miracast, 实时同屏镜像, 画面流畅;支持英特尔无线传屏;支持1080P高清输出。下面我们就来试用一下这款产品。

一、产品外观与细节

除了i Pazz Port Cast外, 配件还有1条Micro USB充电线、HDMI转接线。尺寸约为85×35×11mm, 与前代产品相比体型更“胖”一些, 但依然非常便携。

机身整体为纯黑色, i Pazz Port Cast的LOGO上是一个推拨开关, 朝“Open”箭头方向推开, 隐藏在机身前端的HDMI接口就会伸出来。同时旁边的天线支起, 不使用的时候可以再把开关推回去, 方便携带。另一端是Micro USB接口, i Pazz Port Cast工作需要供电, 用充电线与电视的USB接口连接, 或使用移动电源等供电都可以。侧面有两个小按钮, 左边是重启键, 右边是“FN”键。“FN”键用来切换i Pazz Port Cast系统的各个模式, 比如“DLNA”模式、“Miracast”模式、“Wireless Display”模式。此外, 背面还有镂空的散热孔设计。

二、i Pazz Port Cast试用

我们首先要把i Pazz Port Cast与电视连接。可以使用配件中的HDMI转接头与i Pazz Port Cast的HDMI接口连接, 转接头再与HDMI线相连, 插到电视机的HDMI接口上。接着是Micro USB接口, 用充电线与电视机的USB连接, 给i Pazz Port Cast供电。

连接好后, 电视的信源选择HDMI, 电视上就出现i Pazz Port Cast的界面了。我们一起来试用i Pazz Port Cast的两种模式:1、使用i Pad mini2通过Airplay协议推送;2、使用安卓手机通过Miracast模式推送。两种模式用“FN”键进行切换。

1、通过Airplay协议推送

Air Play是由美国苹果公司推出的无线技术, 允许用户在许可的扬声器底座、影音接收器和立体声系统等设备上无线同步播放影音。

在Wi Fi网络里选择名称为“Smart Cast 659”的无线网络进行连接。

接着在快捷栏的Air Play设置里选择连接“Smart Cast659”这个设备, 并打开镜像推送开关。

这样通过i Pazz Port Cast和Air Play镜像, 我们就能将i Pad mini2显示屏上的所有内容同步推送到电视上了。

这时我们打开一款游戏, 在电视上完全能够同步显示, 延迟也不多, 基本不会影响操作。有些游戏推送到大屏幕上玩能得到更畅快的体验。

照片推送也很方便, 亲朋好友聚在一起, 正好可以分享旅游见闻或日常生活点滴。

i Pazz Port Cast同时也支持音频推送, 可以把i Pad mini2里的音乐推送到电视上播放。

最实用的功能要数网络在线视频推送了。因为很多朋友的家里还使用着非智能电视, 不能直接收看网络视频。把手机或平板电脑上的在线视频同步到电视上, 大屏幕收看视觉体验更出色, 使用i Pazz Port Cast操作也很方便。

除此之外, 还可以在电视上演示PPT、Word等办公软件, 非常实用。

2、通过Miracast模式推送

接下来我们按一下“FN”键, 把i Pazz Port Cast切换到Miracast模式。使用安卓手机的Miracast功能推送。

选择Miracast模式的话, 需要智能手机、平板设备支持Miracast协议, 安卓系统4.2以上版本及部分安卓4.1系统支持。

在手机端的无线显示设置里打开Miracast功能, 扫描无线设备, 找到有“Smart Cast”字样的设备进行连接。

连接成功后手机屏幕上的所有内容也可以同步推送到电视上了。看着电视玩Flappy Bird真是别有一番滋味。此外, 还支持图片推送以及音乐播放。i Pazz Port Cast还支持1080P高清输出, 我们播放一段1080P高清视频, 过程流畅无卡顿。

信息推送技术综述 篇6

在现有技术中,用户主要基于两种方式获取互联网信息。一种是用户通过浏览器主动查询消息(pull),网站只能被动地接收访问;另一种则是服务器主动向用户发送消息(push),变被动模式为主动模式。推送技术是根据用户需求,有针对性地将用户感兴趣的信息主动发送到用户的计算机中。该项技术应用广泛,涉及广告、商品、多媒体、好友、景点等各类信息的推荐。其优点在于对用户要求低、适用面广、及时性好。

1 推送依据的属性

近年来,随着推送技术的快速发展,专利申请量也随之增加。如何从海量资源中选择合适的内容推送给用户,是信息推送技术的研究重点。推送系统基于用户的属性信息,分析或预测用户需求,尽可能向用户推送合适的信息,提高用户粘度。目前,推送系统主要依据以下几类属性确定推送内容。

1.1 地理信息

推送系统基于用户当前所在的位置发送消息,便于用户实时获取周边信息,例如:旅游景点推荐、交通路况报告。另外,考虑到地理位置相近的人群往往存在相似的需求,系统还可以将与用户处于相近地理位置的人群热点信息发送给用户,提高推送消息的命中率。依据地理信息推送消息,主要运用在交通、社区等方面,具有针对性强且准确的优势。然而,这种方式在消息的内容上存在局限性,应用领域较窄。

1.2 用户静态属性

在信息推送技术发展初期,系统主要依赖用户主动提供的属性(例如:用户注册的性别、年龄、职业、血型、星座、学历和生日,或是与登录信息相关的IP地址、用户标识)向用户推送消息。这类属性属于用户的静态属性,一般不会变化。服务器推送与用户静态属性相匹配的信息,属于针对用户需求的主动推送,简单易行。但是,这种方式及时性较差。由于用户需求会随着时间改变,始终以静态属性推送的消息,往往不能满足用户新产生的需求。

1.3 用户动态属性

在技术发展后期,越来越多的企业不再满足于被动地接收用户提供的属性,转而主动挖掘用户需求,甚至是预测用户的潜在需求。这类技术突出表现在基于用户历史操作行为(例如:经常输入的关键词,或是曾经购买的商品)或是基于当前操作行为(例如:当前浏览的网页)进行推送。

1.4 用户反馈

用户接收服务器推送的消息,并不代表用户接受了服务器推送的消息。如果推送的消息未被用户查阅,那么这次推送并不算成功。被推送者对消息的反应,即反馈信息,往往是最能体现推送效果的参数。结合用户反馈信息,及时调整推送策略,有助于提高信息投放效果。

1.5 相似群体

基于同一群体中其他人的属性信息进行推荐,这也是信息推送技术的一大分支。基于群体的不同,可以分为两种情形:一种情形下,涉及的群体是用户真正处于的群体,如社交圈上的好友、同一社区的邻居。另一种情形下,系统将具有相同兴趣或偏好的用户集合成一个虚拟群体,并基于虚拟群体推送消息。虚拟群体的建立,有效地解决了用户社交圈狭窄,提供信息不足的缺陷,为用户挖掘真正与其兴趣一致的“好友”,更便于挖掘用户的潜在需求。因而,基于虚拟群体推送消息,相对于基于真实群体,其准确度往往更高。

1.6 用户自定义

除前面描述的几种属性外,用户也可自行设置推荐条件,只有符合用户自定义标准的内容才被推送。这种方式通常用于订阅期刊等情形。

2 推送时机

除了推送依据的属性之外,合适的时机也是推送技术研究的重点。推送技术由服务器进行消息的主动推送,增加了服务器工作的压力。为了避免资源的浪费,服务提供商需要设置合适的推送时机。

一种简单的方式是设置固定周期,定期推送资源。这种方式实现简单,却不够有效,可能导致推送消息不够及时。另一种方式是在资源更新时推送。这种方式减轻了服务器的压力,但仍然存在局限。倘若推送时间不恰当,对用户造成困扰,将无法构成一次成功的推送。因而企业在提高推送内容准确性的同时,也在研究如何把握合适的推送时机,使得整个技术更加智能。例如:申请号为201410666098的中国专利申请,其提出了一种信息推送方法,旨在接收用户输入的多个手势操作,通过用户的手势操作确定用户处于无聊状态,在用户处于无聊状态时向用户推送其感兴趣的信息,更符合用户的需求,推送时间更合适。

3 结束语

推送技术是一种将适合用户的资源自动推送给用户的计算机数据发布技术。如何在合适的时机将合适的内容推送给用户,改进推荐质量,提高服务水平,是信息推送技术研究的重点。根据推送依据的不同,可以分为基于地理信息、用户静态属性、用户历史行为、用户当前行为、用户反馈、相似群体(实际群体或虚拟群体)以及用户自定义的规则几大技术分支。在技术发展后期,服务器不再依据单一的因素决定推送内容,转而同时考虑多种因素。同时,现有技术不再满足于简单的定时推送,进而研究如何更为智能地选择时间点,力图在不干扰用户操作的情况下推送消息。

当前研究信息推送技术的企业众多,因而发明专利申请想要被授予专利权的难度较早期更大。国内企业应该加大研究力度,研发核心专利,提高知识产权意识,才能更好地占据市场,提高企业核心竞争力。

参考文献

[1]刘迎清.国内信息推送研究综述[J].长沙大学学报,2006(5).

[2]徐青云.信息推送在个性化信息服务中的发展趋势[J].现代情报,2010(3).

[3]黄艳娟.基于RSS的图书馆个性化信息推送服务[J].情报科学,2006(7).

资源推送 篇7

对于用户来说,推送技术的优点在于可以轻易的及时获取信息,而不需要自己时时关注,因为有服务提供商的推送消息提醒。对于服务提供商来说,使用推送技术可以更有力的保持用户的粘连性,比如新浪微博、微信等社交软件,用户所关注的人一旦有更新,马上就可以知道,随时互动,同时也大大提高了应用的使用频率。推送技术带来的可以说是商家与客户的双赢。

1 推送技术的原理

1.1 苹果操作系统(IOS)的推送实现原理

推送的概念很久以前就有,但实际上是被IOS发扬光大的。资深iPhone用户应该还记得,IOS在4.0版本以前是不支持多任务的,但是3.13版本的IOS却已经可以在后台挂QQ了,这是怎么做到的呢,答案就是推送。下图展示了IOS的推送过程。

Provider:可以理解为发起推送消息的服务器,它跟客户端应用(Client app)相关,如i Phone QQ消息服务器。

APNS:Apple Push Notification Service,苹果推送消息服务,苹果公司官方搭建的推送服务器集群。

IOS:运行在i Phone上的IOS。

Client App:IOS上的客户端应用,用来接收推送消息。无论此客户端应用是否在后台运行,它都是可以收到推送消息的。

推送的工作流程如下:

1)Provider把需要发送的消息和目的IOS设备标识发送给APNS。

2)APNS在自身数据库中查找已注册Push服务的IOS设备标识,如找到,则将消息发送给对应的IOS设备。

3)IOS接收到推送消息,再传递给对应的App,弹出推送通知。

实际上就原理而言,推送并不是什么新技术;但是苹果率先把这个功能整合进了IOS,我认为这就是一个奇妙的创新。细心的用户可能会问,为什么Provider不直接发送消息给Client App,而要去APNS走一遭呢?这就是IOS的高明之处。试想,如果Provider直接发送消息给Client App,那么就会如下图

其中,每一个应用都必须与对应的推送消息服务器建立物理连接,如果有N个应用有推送功能,IOS里就会建立N个连接。对于一个移动终端来说,这种方式必然会增加耗电,增加网络资源消耗,同时降低了安全性。而且,在IOS4.0之前的单任务系统下,一次只能运行一个应用程序,后台挂QQ是一个不可能完成的任务。

然而,如果采用苹果设计的推送服务,就会变成下图这种情况

IOS系统只需要保持一个与APNS的物理连接,然后所有的App都可以共享这一个连接来接收推送消息,由IOS负责分发这些不同的推送消息到对应的App,这简直太棒了,大大节省了系统资源。要知道电力就是移动设备的生命,而且即使是单任务系统下,IOS也游刃有余,只需要在收到推送消息时,激活对应的App。

1.2 Android系统的推送实现原理

作为与IOS分庭抗礼的移动操作系统,Android系统的推送是如何实现的呢?

首先面临的问题是,Android系统上有类似于苹果APNS的服务吗?答案是有的——Google Cloud Messaging(谷歌云推送消息服务,简称GCM)。不过可惜的是,由于Android是开源系统,许多手机厂商在为自己的产品搭载Android的时候,都会做一些去google化的深度定制开发,顺便加上自己的服务取代google的服务,所以用户买到的Andoird手机,并不一定带有GCM服务(据统计市面上流行的移动Android设备大概只有20%内置此服务)。这种形势下,对于一个App开发者,一般是不会采用这种不确定的实现方案。

如果不使用google的服务,似乎就只能另起炉灶自己动手丰衣足食了。

1.2.1 轮询方案

这种方案大概是最容易想到的解决方案。轮询实际上就是传统的Pull模式,很多传统的软件也是这么实现的,比如outlook就是每5分钟查询一次邮件服务器。实现思路就是Client app定时向服务器主动查询看是否有更新。这种方式的优点是实现简单,缺点是服务器压力大,实时性差。试想好友发了条QQ消息,过了5分钟才收到,足以令人抓狂。同时浪费网络资源,比如长时间无推送消息的情况下,Client App依然会不停的向服务器做无效查询,如果用户量太大,密集的查询可能会让服务器崩溃,如果应用的定位是小规模使用并且对实时性要求不是太高的情况下,轮询也不失为一种解决方案。

1.2.2 长连接方案

对于轮询方案,采用HTTP协议即可,因为是客户端主动发起的查询,所以不用保持连接。而长连接方案就如图2所示,由Client App与服务器保持一个可靠连接,如TCP连接,通过发送新跳包的方式保持连接存在,当服务器有更新时,就可以直接通过这条连接发送数据给客户端,这种方式的优点是可以保证实时性,缺点就是如果应用太多,则需要同时保持N个物理连接,对手机资源消耗较大,特别是网络流量和电量。同时需要自定义一套应用层协议并且实现它,开发成本较高。

1.2.3 开源解决方案

1)使用XMPP(可扩展通讯和表示协议)。XMPP是基于XML(可扩展标记语言)的协议,它用于即时消息以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。这种方案的优点在于协议成熟、强大、可扩展性强,目前主要应用于许多聊天系统中。缺点同样明显:XMPP较复杂、冗余(基于XML)、费流量、费电,需要自己部署服务器,成本较高。目前已有开源的Java版开发实例androidpn(android push notification)。androidpn是一个基于XMPP协议的java开源实现,它包含了完整的客户端和服务器端。

2)使用MQTT协议。MQTT是一个轻量级的消息发布/订阅协议,它是实现基于手机客户端的消息推送服务器的理想解决方案,并且现在有免费的实现可以直接使用。这种方案的优点在于MQTT协议简洁、小巧、可扩展性强、省流量、省电,缺点是不够成熟、不开源、部署硬件成本较高。wmqtt.jar就是一个IBM提供的MQTT协议实现。我们可以从这里(https://github.com/tokudu/Android Push Notifications Demo)下载该项目的实例代码,并且可以从这里(https://github.com/tokudu/Php MQTTClient)找到一个PHP服务器端。

目前,在市场上流行的Android系统还处在百花齐放百家争鸣的状态,因此长连接方案和开源方案没有本质区别,没有一个统一的推送服务平台,各家的应用都是各自为战。即使使用开源方案,N个应用N个连接的情况在所难免,好在android的硬件升级更新很快,对于这些系统开销还是可以承受的。相对于长连接的方案,使用开源方案可以免去自定义和实现应用层协议的工作,便于进行快速开发。

2 为什么不可以用以下方案?

2.1 服务器主动发起连接到Client App

如果服务器可以主动连接到Client App,那么一切问题都不是问题。Client App不用保持长连接,需要用的时候才建立连接,最大程度节省网络资源和电力。

然而,由于Android客户端所处的网络环境一般都比较复杂,通常都是经过了好几层NAT(Network Address Translation,网络地址转换)才连接到服务器,同时服务器并没有穿透NAT的能力(只有极少数几种情况才有可能服务器连接到Client App,具体请参考NAT技术相关文献),所以作为服务器只能被动的等待客户端主动发起连接。至于P2P穿透NAT的技术,在这里并不适用,因为P2P也是需要客户端先主动发起连接到服务器,获取其他P2P客户端的信息。

2.2 UDP协议

使用UDP协议,可以做到服务器主动向Client App发送消息(Client App首先向服务器发送一个UDP报文,告知其自身的地址,之后便可等待服务器消息,具体可以参考P2P穿透NAT原理),但是这种方案最大的问题是不可靠。由于UDP是无连接的协议,所以服务器向客户端发送的推送消息并不保证能到客户端。所以,除了轮询方式之外,要实现稳定的推送,必须适用连接可靠的协议,如TCP。如果应用场景对可靠性要求不是太高的情况下,实际上还是可以考虑UDP的。

综上所述,在Android系统上,想要兼顾开发难度和效率实现推送,采用开源方案是比较合适的。但相对于IOS高度整合的推送功能,Android系统的推送确实是一个不大不小的硬伤。

参考文献

[1]Michael Yuan.Ringful Health[EB/OL].(2012-05-25).http://www.ibm.com/developerworks/cn/mobile/mo-ios-push.

[2]Apple Inc.Local and Push Notification Programming Guide[EB/OL].(2013-04-23).https://developer.apple.com/library/ios/#documenta tion/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html.

[3]Saint-Andre P.Extensible Messaging and Presence Protocol[EB/OL].(2004-10).http://xmpp.org/rfcs/rfc3921.html.

[4]张逸炎,任品毅,李凡.移动终端即时消息推送系统的应用开发[C].第十七届全国青年通信学术年会论文集,2012.

[5]张长学,张伟,董智明.移动推送技术面面观[J].移动通信,2011(5):21-24.

基于OMAPush的APN推送 篇8

关键词：OMA,PUSH,PULL,APN,IMSI

Push技术是相对于Pull技术而言的, Pull就是传统方式的客户端发起一个request请求, 服务器给予响应并把相应的请求内容发给客户端的一个过程;push是指客户端并未发起任何请求, 而是由服务器主动发送一些信息到客户端的过程。O M A Push技术是一种更有利于移动终端自由访问互联网的技术, 尤其是在终端设备输入受限的条件下, Push技术能更好的发挥手机等移动终端的特点。

OMA (Open Mobile Alliance) 组织作为运营商和各种终端相关厂商的联合组织, 通过制定相关协议和标准, 达到实现跨国家、跨运营商和跨终端业务的互通。其前身W A P论坛在标准的制定和无线解决方案上做出了许多具有建设性和发展性的贡献。OMA组织是在很大程度吸收已有技术的基础上, 结合无线终端环境, 致力于为无线终端制定和建立一个统一的技术体系架构, 促进全球无线技术和移动业务的融和, OMA Push规范亦使得手机上的数据通信功能得以广泛实现。

1 OMAPush规范概况

O M A Push规范定义, 其主要包括推送发起者 (PI) 、推送代理网关 (PPG) 和推送客户端 (PC) 三个功能部分, PI位于Internet中, 通过推送访问协议 (PA P) 同PPG通信, PPG是Internet网和移动通信网之间的访问接入点, 通过推送空中传输协议 (Push-OTA) 完成从PPG到推送客户的数据传输任务。基本的工作过程如下:当有消息要推送给客户时, PI首先根据消息的内容和性质构造推送消息, 通过PA P协议向PPG发出推送请求, PPG收到请求后进行一些必要的处理工作 (包括压缩、协议转换、安全认证等) , 然后通过Push-OTA协议将推送内容传送给客户端, 客户端收到推送消息后, 根据消息内容和服务类型同用户进行交互。

Push-O TA协议负责将Push内容从PPG网关传送到用户的终端, 该协议主要提供两种服务类型, 一种是面向连接的, 一种是面向无连接的, 分别对应IP Push和SM S Push。目前商用中大多采用的是面向无连接的, 仅需要预留端口的方式即可完成通信;对于使用连接会话的推送, 需要在PPG和PC之间预先有一个激活的会话上下文, 此前这种方式由于对于网络和终端设备的要求过高应用得较少, 随着终端技术的不断进步以及移动互联网越来越深入人们的生活, 面向连接的方式可能会逐步得到广泛应用。

由于SMS Push技术实现相对容易, 成本不高, 一旦运营商向SP开放对应的端口, SP就可以自己搭建PI发送SMSPush, 导致国内的SMSPush大多是广告和垃圾消息, 给用户造成了负担并在社会上造成了负面影响, 运营商也在逐步收回此前开放给SP们的端口以减少垃圾消息的产生和对网络资源的浪费。因此如何更好更有效地利用SMS Push一度成为OMAPush讨论的焦点。

2 用户终端设备APN实现方式

目前最常见的用户终端设备无疑是手机, 以智能手机为主。无论IOS、A ndroid、Window s平台的智能手机, 都会在用户插入USIM卡后自动匹配对应运营商的网络设置, 普通用户并不关心网络设置详细参数, 也不希望需要用户手动去配置或者修改网络设置, 只要能够正常连接网络即可。

在A PN的配置实现上, 终端生产厂商目前主流的有如下两种方式:

2.1 定制终端的APN预置

目前运营商营业厅里售卖的机型大多是定制机型, 这也是国外终端销售的主流方式。所谓定制, 指由手机厂商严格按照运营商对终端的需求进行实现和生产, 其中A PN预置也是需求之一。每个运营商各个网络下的A PN都是既定的, 因此当一款终端确定是某个运营商某个制式后, 就将对应的A PN预置到终端里, 预置的A PN不允许被删除, 用户可以新增A PN。

2.2 渠道终端的APN适配

所谓渠道终端, 指终端生产厂商根据市场情况自行研发和生产的机型, 为了扩大销售市场但不频繁更改软件版本, 通常在A PN设计方面会采用这样的方式, 即将全球所有目标销售市场上所有使用该网络制式的运营商的A PN全部写入到软件中, 当用户插入U SIM卡后, 根据U SIM卡对应的IM SI中运营商编号来进行匹配, 如46000对应中国移动G SM网络, 依次将A PN配置到该终端中可供用户查看, 同时将第一个APN进行激活。

3 基于OMAPUSH的APN推送实现

目前大部分终端的A PN都是上述两种实现方式, 可以满足常规状态的使用, 但当用户使用这样的终端出差或者旅行去了其他国家, 为了更方便使用当地网络, 购买了漫游地运营商的U SIM卡插入终端, 如果该终端是定制机型或者漫游地并非该终端的销售区域, 就会导致插入新的U SIM卡后A PN并未更新的情况, 那么用户使用数据业务就必须手动添加网络设置。

为了解决类似的场景问题, 在此提出一种推送A PN的方式, 即当移动终端每一次开机并成功驻留到某个小区后, 由运营商服务器将用户USIM卡对应网络的A PN通过SMS Push到终端, 终端设备需能够正常识别并解析, 将SMS Push中带的APN与本机当前的设置进行对比, 如果完全相同不做任何处理, 如果不同则更新手机设置为接收到的数据, 此后的数据业务自动使用更新后的APN, 整个过程无需知会用户, 由终端设备后台完成, 该消息不被保留到收件箱中。

4 结束语

本文提出了一种基于SMS Push推送A PN的方式, 即从服务器侧Push网络设置到终端设备, 前提是服务器侧和终端设备都需要做相关的配置和实现。这种动态推送APN的方式比起传统的静态A PN预置或适配, 能够给用户带来更好的用户体验, 也方便运营商更改或者升级网络配置, 值得运营商借鉴并推广。

参考文献

[1]WAP-250-Push Arch Overview-20010703-a, Wireless Application Protocol Forum, 2001.

[2]WAP-251-Push Message-20010322-a, Wireless Application Protocol Forum, 2001.

个性化推送的缺陷 篇9

在很短的时间内，奇妙的事情发生了，一小时之内，马特的信息流里面全都是品牌推广和广告消息；接着来自Upworthy和Huffington Post的内容也到处泛滥。之后他开始给加沙冲突的内容点赞，比如他点赞了一条支持以色列的消息，第二天他的信息流内容完全转向极右。……他继续点赞，信息流就像洞悉他喜好的精准推荐器，推荐给他所有他“喜欢”的内容。

互联网诞生之初是开放的，只要有了网络我们就连接了整个世界。但是随着推荐引擎的越来越智能化，互联网的发展却越来越偏离提姆·伯纳斯一李的初衷：现在的互联网世界已经被这些‘‘过滤泡泡”所包围，就像马特在Facebook的个人首页一样。

所谓的“过滤泡泡”（The FilterBubble），狭义来看，就是互联网服务根据你的个人特征、行为和在互联网上的社会关系，做出的个性化内容定制。Google的个性化搜索、微博的个性化内容推荐、亚马逊和Netflix根据你过往的内容消费记录做的个性化推荐，甚至你在伦敦听u2音乐会时，你打开Twitter会发现自己的Feed中能被精准推荐一个带有u2的描述文字和图片的Spotifv，以及微信朋友圈，这些都是“过滤泡泡”世界中的典型场景。没错，你使用的主流互联网服务，无论国内国外，都一样。唯一的不同是，国内的“过滤泡泡”演化速度要慢一点，即使是两个互联网平行世界，总的趋势仍然保持着一致。

“过滤泡泡”被设计的初衷是典型的“互联网思维”驱动，或者更准确A说，是用户导向驱动。它的逻辑是如果我足够理解用户的话，那么我应该为用户推荐他感兴趣的内容，判断的依据也有很直观且客观的衡量标准：点击率。点击率是一个好东两，它完美平衡了用户和公司的共同利益：点击概率高，说明用户越喜欢；而一条内容如果点击率高，用户则更依赖这个互联网服务，即使是商业广告也能获得更好的收益。以制作《纸牌屋》而股价大涨的Netflix为例，用户租借的影片中，有高达60%的比例来自系统算法推；Netflix能预测用户对某部片子的评分，误差范围不会超过半颗星。真是一个完美的商业模式，我们只需要不断改进算法，用户等着喜欢的内容喂过来，everybody’s happy。这也解释了’为何过去五年来，传统编辑部一个一个解散，无论国内国外。

“过滤泡泡”致力于为所有人打造一个专属的个性化世界。人们享受它给人带来的好处，却很难注意到这个专属于自己的个人小世界背后所隐藏的风险。这些风险，正是Eli Pariser通过“The Filter Bubble”一书所极力想警示用户的：

1、风险之一是，在“过滤泡泡”的世界，使用者醉心于消费内容，让搜索引擎产生误解，以为真的掌握人心。

2、使用者只接触“过滤泡泡”们精心定制化的内容，定制化意味着失去一般性，这些内容无法反映真实世界的样子，只能呈现特定的狭隘观点。对于人类来说，只用这样的观点面对世界，恐怕会产生极为扭曲的认知。

3、“过滤泡泡”把相似的人、事、物聚集在一起，同时将整个网络切分为无数片段。

研究表明，身边的人思想和自己差别越大，越能培养眼界开放、类别宽广的心性。双语人往往比单语人更有创意；在职场里，和各公司互动的员工通常比只和自己公司互动的员工懂得触类旁通。如果每个人都只跟自己相近的人往来，不与相异的人接触，将造成这个世代的种族隔离与近亲繁殖。可惜的是，“过滤泡泡”的设计原理与多元思想、多元族群的理念背道而驰，“过滤泡泡”的用意不在于引入新文化。接触异己能开放见识，而活在“过滤泡泡”里的我们会错过这一类的好处。

“过滤泡泡”里的世界人们变得越来越同质化也得到了数据的证实。最近皮尤研究中心发表了一份针对社交媒体的研究报告，报告称，社交媒体降低了人们表达意见的可能性，尤其是当他们认为自己的看法与朋友不同的时候。人们在社交媒体上讨论不同观点的情况甚至比线下世界还要低。比如愿意在家庭饭桌上讨论敏感问题的占40%，而在被公认为重大事件讨论和传播的社交媒体Twitter上比例却最低，只有14%，非常不愿意的比例达到T40%。人们忌讳在与自己相似的人群中发生观点冲突。

这份报告从另外一个角度证明了人们在“过滤泡泡”的世界中会走向趋同：如果Facebook用户认为，自己在该网站上的好友同意自己的立场，他们在Facebook上参与讨论的可能性就会增加1.9倍。如果态度十分强烈，愿意参与讨论的可能性就会增加2.4倍。有趣的是，受教育程度较低的人更有可能在Facebook上畅所欲言，而受教育程度较高的人，则更倾向于在Facebook上保持沉默，更多在家人或朋友中表达自己的观点。

随着个性化程度的深入，人们除了更不愿意在社交网络上表达自己真实的观点，媒体的未来可能和你我的期望有所出入。从互联网早期开始，推广互联网的人士断言，互联网是一种主动性的媒体。“看电视的人基本上是想让大脑休息，想动脑的时候改用电脑。”这是2004年乔布斯接受“Macworld”采访时表达的观点。十年之后再回过头来审视，乔布斯的看法未免太乐观了。个人化过滤越精良，我们就越不需要费力去挑选节目。以笔者个人为例，笔者在YouTube上看过几次CoC（部落冲突，一款手机游戏）的视频教程、Apple的广告、Facebook和Twitter关于广告产品的视频之后，再打开YouTube前面整整四屏内容全都是CoC、Apple、Facebook、Twitter相关的视频推荐。

这也推导出了“过滤泡泡”背后最大的隐忧：“过滤泡泡”经常自动清除知识地图上的空白点，把用户自知的未知变成不知的未知。阅读报纸的人习惯略过大部分新闻，只精度部分自己感兴趣的消息，但在这个过程中读者至少知道有些报道被忽略了。即使对国际政治不感兴趣，不读内文你仍然会知道ISIS是一个热衷于砍头的恐怖主义组织。因为在浏览报纸各个版面标题的过程中，知道“ISIS是一个恐怖主义组织”就完成了一个将不知的未知转化为自知的未知。

最优良的工具是让资讯版图上的用户具有方向感，例如让读者知道自己站在图书馆的哪一区，让报纸读者能浏览头版各大标题。由于个人化过滤器通常没有拉远镜头的功能，使用者容易迷失方向，明明站在一块多元文化的大陆，却认定自己置身一座狭隘的孤岛。而现在的“过滤泡泡”们，正在让人们在信息地图中迷失。

你的身份塑造你使用的媒体，遗憾地是，这种逻辑有一个致命缺点：媒体也会反过来塑造你的身份。这种情况非常像自证预言（Self-fulfilling Prophecy）：当人们相信某件事情会发生（事实上那件事情原本并不见得—定会发生），那么此事最终真的发生了c这是美国社会学家罗伯特·金-莫顿提出的一种社会心理学现象，莫顿教授用银行挤兑的例子说明自证语言的作用机理：一家银行本来运作得好好的，但不知怎么就开始有谣言说这家银行要倒闭了。流言越传越广，越来越多的人开始信以为真，开始有人跑到银行把自己的存款提走；进而恐慌开始散布，并且变得真实，更多的人冲进银行提走自己的存款……最终，挤兑发生了，银行真的倒闭了。我们现在即将进入自证预言的时代——互联网误判我们的特质，而这些错误的特质进而成为我们真正的特质。

基于局域网的数据推送 篇10

关键词：数据推送,局域网,广播,组播

1. 引言

在网络中许多数据传输都采取拉的形式,即当客户机需要数据的时候,它向服务器发出请求,服务器接受请求时后把客户机需要的数据传输给客户机。但是这种传输方式对大量基于同一内容的数据传输存在明显的缺陷。首先相同内容会被传输多次,这样服务器存在大量的时间占用,而带宽也不能被充分利用。现在有许多研究[1,2,3,4]使用数据推送方式把数据发送到客户端。在局域网中,存在大量一致性的数据传输的需求,使用数据推送的方式可以有效地提高系统的数据传输效率,并能够节省大量的带宽。在局域网中可以很方便地实现网络的组播和广播。组播是成组的数据传输模式,在这种数据传输模式下,本组某个主机发送的数据,本组所有的主机都可以接收到这个数据。广播是组播的一种特殊情况,它是指在局域网中,对于某个主机发送的数据本网中的所有主机都能接收到。在局域网中可以使用广播与组播的方式实现数据的同步。

但是众所周知的是广播与组播的通信使用的是UDP的通信协议,在这种通信模式下,数据传输的可靠性不能由UDP协议来保证,这就给组播或广播条件下的数据传输协议提出了更高的要求,并增加了它的复杂度。但是幸运的是在局域网数据传输中,数据出错的概率较小,这是使用UDP进行数据传输的前提条件,局域网条件下使得UDP数据传输速率大大高于TCP的数据传输速率。

2. 数据传输结构

图1系统数据传输结构

系统的数据传输结构如图1所示。首先客户端主机在某一端口等待命令,当服务器发出命令后,客户端对命令进行处理并把处理结果发送给服务端,服务器根据返回结果进行下一步的工作。

3. 数据传输帧结构

服务器命令和客户端数据帧结构如图2所示。#是开始字符$为结束字符。中间是命令或结果字符串。由服务器发送给客户端的是命令,客户端返回服务端的是结果。

在局域网中进行数据推送首先是服务器发送命令给客户端请求进行数据推送。客户端接受请求,并返回结果。文件推送命令语法如下:

SEND space PORT space LENGTH space PATH

SEND为发送命令;space代表空格;PORT代表端口号,说明客户端需要在什么地方接收数据;PATH说明文件的默认路径。该命令表达的语义为把数据发往PATH所指的文件,数据的长度为LENGTH,PORT为客户端接收数据的接口。例如如下命令:

SEND 1200 3230 D:test.doc

上面的命令把数据发往D:test.doc所指的文件,数据的长度为3230字节,1200为客户端接收数据的接口。当服务器发送SEND命令后,客户机在1200UDP端口监听来接收数据。当监听成功向服务端发送110字符串表示SEND命令完成,或510表示SEND命令执行错误。当命令成功以后,服务器就会向客户端发送数据。但是UDP协议不能保证数据能够到达客户端,所以必须有机制保证数据能够按序到达客户端。

有两个方面使数据不能到达客户端。首先在数据传输中数据可能丢失,因为是局域网,这种可能性较小。第二服务端数据发送太快,客户端来不及接收,使得客户端缓冲区溢出,进而使数据丢失。数据的丢失可能使接收数据顺序改变。发送数据的格式:

序号占4个字节总共可以有232-1个序号。#为数据的开头,$为数据的结尾。中间可能会有#和$字符,所以有一个转义字符@。@#为字符#,@$为字符$。@@为@字符。使用字符填充的方法就可以把开始字节和结束字节区分开来。

错误报告抑制报文格式如图2所示,但是命令与发送数据命令不同,其数据如下:

DFERR

这个命令只是对某个主机所发并不是对所有主机,主机接收端口是命令端口,而不是数据端口。错误报告报文格式如下:

310 space POS

其中POS为接收错误块号。服务器就从POS块开始发送。

4. 数据传输描述

服务器在发送数据时首先从序号为0的数据块开始,每发一个数据块把序号加1。计算序号完成后,在对数据块前后插入#和$字符,表示数据块的开始和结束。扫描数据块内部如果存在#、$和end的字符就在前面增加一个@字符。把修改过的数据帧发送出去。因为以太网数据帧的最长长度为1500个字节,所以规定数据块的长度最多为1000个字节,这样在传输中就不会分片。

当客户端接收到数据推送命令后,就在相应的端口等待接收数据,同时启动计时器并设置超时时间。在超时的情况下,客户端关闭接收端口,同时向服务器发送出错数据帧序号;若没有超时,首先看是否有数据帧的开头与结尾,如果只有开头,则继续等待接收并重置计数器,若超时向服务器发出错误帧序号,否则查看接收的数据帧有无结尾,若无就一直接收直到接收到数据帧的结尾。若接收到2000个以上的数据帧还没有结尾,就说明数据帧错误,并发出错误帧的序号。若接收到数据帧的开头与结尾把数据帧接收下来,并删除转义字符@、开始字符#、序号和结束字符$把数据写入文件中。因为处在局域网中,数据丢失的情况并不多见,所以不会对服务器造成很大负担。

虽然处在局域网中,由网络造成的数据丢失的情况并不多见,但是网络中主机各不相同,在进行大数据量推送时,主机的接收速度是较大的问题。如果主机接收速度慢,接收缓存可能会丢失数据。而数据推送的速度由网络中接收速度最慢的接收主机决定。服务器使用迭代的方法找出最大发送速度。首先服务器以全速发送数据,当遇到主机发送的接收错误报告后,变成每500ms发送一次数据,如果在规定的时间内没有错误报告发出就可以以250ms为周期发送数据。如果在规定的时间内有错误报告就会在(500+250)/2的时间内发送数据。就这样使用这种迭代的方法找出发送数据的最佳速度。如果一个地址在规定时间内发出的错误报告达到16次,就发出错误报告抑制报文,此主机就不再发出错误报文,并直接在该主机上显示错误提示。

5. 结论

本系统通过测试表明,系统可靠性达到99%以上,局域网中的所有主机都能接收到这个数据。数据的发送速度明显高于使用FTP进行数据传输的速度。由于实现了广播和组播的数据发送方式,大大提高了数据发送的效率,减少了带宽的占用。

参考文献

[1]王凯渠芳王辉.利用Web挖掘技术实现个性化推送服务[J].情报杂志.2006,(11):86-88.

[2]申超王健.基于J2EE体系结构的新闻推送系统的设计研究[J].计算机应用与软件.2006,32(9):61-63.

[3]薛真真.基于服务器推送和事件流处理技术的实时Web系统研究[D].浙江大学:计算机与软件学院,2008.