谈我在做IM时候遇到的几个问题

jobsccnu 2006-04-24 10:28:20

我做IM时候，遇到以下几个问题，希望有朋友可以和我讨论一下：
开发环境：
后台：linux+cpp+mysql
前台：vc
1、点对点通讯的时候，如果完全用udp进行点对点，会存在nat穿透问题，
有时候可以成功，有时候不能成功，那么就需要用服务器转发，
这样就需要client和server时刻保持连接,这样耗费资源将非常大，
（linux内核会为每个连接保持20m的资源空间）
2、群消息
我采用组播机制，但是发现组播无法穿透网关，难道要我对每个用户逐一发吗？
另外，因为我的服务器属于被动响应，client可能处于私网内，server无法主动connect
client。
3、广播消息
我采用广播，那么路由器会阻止广播，难道我也要一个个发吗？
4、以上问题，不知道qq都是怎么实现的呢？
听说qq的群离线消息只发最近多少条，不知道是否有这回事。
希望有时间关心这个问题的朋友可以指导一下，谢谢。

...全文

389 3 打赏收藏转发到动态举报

写回复

3 条回复

切换为时间正序

请发表友善的回复…

发表回复

MrPotter 2006-04-28

打赏
举报

回复

群聊就是服务器中转的

daironghua 2006-04-27

打赏
举报

回复

我也正在做IM，与LZ有相同问题：
1、UDP P2P 实现了，但得考虑不成功时Server转发;
2、多方会话采用组播，在局域网内可以，但不能跨越路由，即无法跨域组播;
3、为什么要广播？如果组播能跨域，广播不需要的;
4、我也想知道QQ 的群聊是什么机制实现的？？

是组播吗？我查了资料，全球组播地址需要申请的，QQ 用组播实现多放会话也不像

期待高手解释一下

netsys2 2006-04-24

打赏
举报

回复

1、用服务器转发
----->不一定实时，可以减少维护量

2、群消息、广播消息
-----》应该服务器控制来发

第1章设计的数据和分析 1 看不懂数据 2 不配看数据 2 为了看数据而看数据 2 不去筛选数据 3 不关注数据采集的方式和方法 4 只用定量数据，没有定性数据 5 设计中的数据分析 5 数据——判断淘宝店铺页面设计优劣的显微镜 7 第2章交互设计 11 交互到底是做什么的 12 好习惯和坏习惯 13 交互设计师容易犯的错误：把自己.禁锢在解决方案之中 15 UI和IxD 16 再谈交互设计、用户体验设计工作 19 中国还很需要交互设计师 19 做产品？拿什么去做 19 第3章信息分类与方法 21 分类、属性、关键词与Tag 22 概描述和泛描述 23 标签与标记的区别 25 信息系统需要与时俱进 26 信息如水，架构如渠 28 了解你的信息 28 当信息遇到互联网 28 第4章视觉设计和规范 30 一名视觉设计师对于网站设计的思考 31 网页版面与报纸版面设计 31 版面布局的平衡性 32 设计规范不应是摆设 34 团队的形成和设计规范的形成应该是同时的 35 设计规范应该是帮助工作的，而不是思路的 35 对于打破设计规范的应该奖惩分明 36 把“规范”当作“产品”来设计 36 产品之道：用规范来封装自己 41 第5章产品评估 46 让产品设计师跟踪测试产品 47 测试的时机 47 测试的相关协作 47 测试依据的文档 47 产品设计师跟踪测试的好处 48 分享自己做跟踪测试的经验和教训 48 小结 49 专家评审 49 所谓的专家是不是够格 49 分数怎么来衡量 50 提出问题的方式是否会激怒设计师 50 怎么样的设计才是好的设计 50 产品设计评估的逆向思维 51 第6章产品经理和设计师 54 谁是合格的产品经理 55 说文解字：从产品说起 55 产品经理的艰难定位 56 PM是个抢饭的角色 56 只有老板才是合格的产品经理 58 产品设计师的核心竞争力 58 为什么设计这个 59 设计能力决定权力 61 絮叨“产品” 62 如果你不是产品经理 65 第7章排序 67 排序的人文魅力 68 排序有什么用 68 技术性排序解决问题 68 情感化排序体现创意 69 排序的人文情境 69 排序最优论 70 网站信息的排序与展示的关系 70 人工干预排序的是必要的 70 网站排序：用户不会看完所有的内容 71 排序不一定是顺序的好 71 排序方式的多样性和默认排序的重要性 72 排序、过滤选项 72 第8章微博 75 我为什么不用微博 76 微博和信息的机会成本 77 类Twitter产品的生命力 78 第9章评论和评价 81 打分进化史 82 我认识的留言和评论 83 站内信不需要标题 85 电子商务网站评论设计探讨 88 是否需要登录后评论 89 是否需要分项评论 90 第10章群组 92 群组功能代替论坛的可行性 93 BBS\Chat room\IM\SNS\Twitter的碎片 94 BBS 94 Chat room/IRC 94 IM 95 SNS 95 Twitter 95 群和论坛里的人和事 96 社区里的人 96 社区里的事或者说信息是什么 97 论坛、群组和临时会话 97 沟通无极限，人人爱扎堆 99 共同的需求和爱好 99 基于某种现象和物质产生联系 100 寻求身份的识别与认同 100 群组良性发展的可行性建议 100 群组功能和用户沟通 101 第11章邮箱和邮件服务 103 关于Gmail 104 设计的小事：新邮件时代 105 邮箱地址是唯一的 107 目前应用最多的还是在注册上 108 邮箱更适合成为云技术集成的核心 108 邮箱可以是全网的通行证 108 邮箱与邮件服务 109 第12章地图服务和网站 111 当地图遇上照片 112 地图，Mashup 114 信息从何而来 114 地图Mashup 115 从需求的变迁看地图的发展 117 地图网站：用户角色和用户需求 118 创建用户角色 118 心智模型 119 可如果没有呢？ 119 Google地图和搜狗地图的信息架构 120 “神奇”的按钮 122 为何Google地图要使用这种架构 123 地图网站的需求功能与体验 123 需求篇 124 功能篇 125 体验篇 127 发展趋势 134 第13章电子商务 135 根据用户购买意愿设计购买流程 136 给麦包包独立商城的一些建议 137 用户角色模型

转载自:http://blog.csdn.net/a_asinceo/article/details/50108971 早在一年之前，就曾负责一款IM移动通信类型的App开发，部分相关的功能都是仿照微信来进行，例如：聊天，通信录，朋友圈等。由于，整个团队都没有IM方面的经验，我们只能不断地摸索前进，所以这篇文章也只适合初级IM开发者来参考之用。

IM （即时通讯）系统是一种大型实时系统，其对技术方面的要求非常高。在APP社交化的今天，很多APP都希望为自己的应用增加IM系统，但却不得其法。本课程抽丝剥茧，搭建一套简IM 系统，先让开发者了解如何实现这类系统，然后会不断的对系统进行扩展，并详述要支撑千万级别的用户，系统架构要经过哪些方面的演变，在每个阶段需要具体考量哪些因素；其中涉及到大型网络开发、协议的制定解析、数据库的优化、负载均衡、监控、测试等方面的知识。相信通过此课程，开发者对IM 系统将有一个全面的认识。

这几年一直在做智能客服，过程中也参与了IM产品的部分功能设计，这里简单的谈谈自己对IM产品设计的一些思考。前面几篇聊完了IM、客服 IM和呼叫中心产品，今天来聊了聊，这几年一直比较火热的智能客服问答机器人。一、背景国内的客服系统厂商的官网上，一般都会有这样的产品解决方案宣传：全渠道智能客服产品或平台。今天我就来说说这里的几个关键词：全渠道、智能、平台。 1.1 全渠道传统的客服渠道是电话，后来伴随着互联网的发展，出现了邮件、网页、各种社交产品、各家的APP，客户反应问题的渠道也跟随变多。渠道变.

概述 14年3月份，在QQ发布带有“支付功能和设备锁”的版本的时候，当时就想写一下IM软件安全登录相关的博客。如今IM软件已经逐步称为一个平台，他的安全性不可马虎！今天有时间，写一段IM登录的文章吧提到登录，作为IM软件第一步可谓首当其冲，用户密码在此处输入，安全意义不言而喻。登录信是最复杂信令之一，可以肯定的说，登录信令的应答码是最多的，不仅仅有200错误码，400错误码，

4,356

社区成员

28,926

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章