Socket编程问题(通讯,很有挑战性的)

rzdir197825 2001-08-15 09:19:05
我想写个Oicq类型的聊天软件(用VC),我的问题是在建立客户端和服务器端的联系时(比如connect,或SendTo)如何获得另一方的IP地址(客户端需要服务器端的IP,服务器端需要客户端IP).假设我的机器运行了Server端,朋友家运行Client端,我们上了Internet后我想向对方发条消息,要知道对方的IP才能发吧,问题是怎样获得对方的ip(朋友家的IP是上网时动态分配的),另外请您讲些计算网络流量(怎么算出来的)的问题以及QQ的设计思想,不胜感谢!
...全文
84 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
boodweb 2001-08-15
  • 打赏
  • 举报
回复
那只有用qq把你的ip告知Client了,呵呵,我就是这么干的
csdnflysnow 2001-08-15
  • 打赏
  • 举报
回复
如果Server没有固定IP肯定不行的,除非你另外有办法将你的Server地址通知到Client端.
rzdir197825 2001-08-15
  • 打赏
  • 举报
回复
忘了说明,我本机运行server端时IP也是动态分配的
csdnflysnow 2001-08-15
  • 打赏
  • 举报
回复
Server端必须要有一个固定的IP地址.否则你怎么连接?
一个思路就是大家通过网上的一个有固定IP的Server互相交换地址后在互相连接.

只需要client知道server地址就可以了,连接时server可以知道Client的地址.
tarkey 2001-08-15
  • 打赏
  • 举报
回复
如果SERVER端IP是固定的就OK了。
如果是用TCP连接,在accept()的时候就能获得一个插口描叙符,然后通过这个描叙符就能
获得client的资料。
QQ的传输数据结构,你可以在WIN2000下把数据包的结构分析出来。
xlfrd 2001-08-15
  • 打赏
  • 举报
回复
客户端上线以后主动登录,OICQ是用的UDP,服务端可以用ReceiveFrom来得到客户端的IP和端口,网络流量就是计算流过的字节数。

早先oicq的包格式:
下面是 Oicq server 通知Oicq 好友上线和下线的消息结构:

struct TOicqUp
{
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本,固定
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本,固定
char Tag3; // 0x00
char Tag4; // 0x00
char Tag5; // 0x81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中,分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址
char cFF; //
char cE[]; // "8685" ,这一位相对固定,随便添一个四位数字
char cFF;
char cDD[]; // exp: "10",0x1f,"107" 基本固定
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。
};
//--------------------------------------------------------
struct TOicqDown
{
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本,固定
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本,固定
char Tag3; // 0x00
char Tag4; // 0x00
char Tag5; // 0x81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中,分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址 // 随便填
char cFF; //
char cE[]; // "8685" ,这一位相对固定,随便添一个四位数字
char cFF;
char cDD[]; // exp: "20",0x1f,"107" 基本固定
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。
};

在Oicq中最常用的消息传送时,Oicq 采用了如下策略: 当二者能直接(点到点)
通讯时,消息就直接的发送到对方,否则重试 N 次后通过Oicq 服务器转发。接受方
在收到消息后返回一个回应信息,发送方就是通过这个信息来确认消息是否已经收到。
消息的结构是:

(注意:本文中所有的 Oicq 协议结构是通过分析得来,不能保证其正确性)

struct TOicqPtoP
{
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本,固定
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本,固定
char Tag3; // 0x07
char Tag4; // 0x00
char Tag5; // 0x78
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 发送方的Oicq 号码。 exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中,分割符都是 0x1f
char cR; // '0' 固定
char cFF; //
char cE[]; // "75" ,这一位相对固定,可能是操作方式。
char cFF;
char cDateTime[]; // exp: "2000-4-10",0x1f,"12:00:12",0x1f
char OutMsg[]; // 发送的消息内容。
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。
};

新oicq的包格式:


三、 与服务器通信的加密
与Decode相对应,是一个加密函数Encode。
void Encode(char *src,int srclen,char *encodekey,char *outbuffer,int *
poutlen)
参数:
src:明文缓冲区。
Srclen: 明文缓冲区的长度。
Encodekey:固定16个字节的加密的密钥。
Outbuffer:输出加密缓冲区。
Poutlen:输出长度的保存地址。
说明:该函数入口地址:15f:456b62。将明文进行加密,密钥为encodekey。用d
ecode函数和同样的密钥可以进行解密。

l 登录服务器:
发送的数据包为
{BYTE b1;固定为0x2
BYTE b2;固定为0x3
BYTE b3;固定为0XA
BYTE b4;固定为0X0
BYTE cmd; 登录服务器为0X15。
WORD seq; 顺序号,从高到低存放
DWORD oicq号;以从高到低顺利存放二进制的OICQ号。
BYTE key[16] ;随机产生的16个字节的密钥。
BYTE buffer[64];64字节的加密内容。
BYTE endchar ;固定为0x3。

最核心的是buffer[64]的内容。用口令调用CalcPassword进行一次计算,然后作
为密钥对0长度的明文进行加密,得出16个字节的结果,再进行加密发送。例如口
令为'abc123',算法为
BYTE passkey[16]
CalcPassword('abc123',6',passkey)

BYTE keycode[16]
int keycodelen=16;
Encode(0,0,passkey,keycode,&keycodelen)


BYTE sndbuffer[51];
memset(sndbuffer,0,51)
memcpy(sndbuffer,keycode,16)
//sndbuffer其余的内容为当前机器的ip等信息,与检查口令无关

BYTE result[64]
int sresultlen=64
Encode(sndbuffer,51,随机产生16个字节的密钥,result,&resultlen)

最后把16个字节的随机密钥和64字节加密后的口令一同发给服务器验证。如果能
用sniffer侦听到别人与服务器的通信,就能进行口令破解。当然也可以通过服务
器进行在线的口令破解,只是速度很慢,没有实用价值。

l 如果登录成功,服务器返回16个字节的密钥--ServerKey。
l UPD数据包的格式为
BYTE b1;固定为2
BYTE b2;固定为1
BYTE b3;固定为0
BYTE b4;固定为0
BYTE cmd;登录为0X15
WORD seq;从高到低顺序,与发送的seq一致。
BYTE msg[56];
BYTE endchar ;固定0x3。
用口令经过一次CalcPassword计算,得出16个字节的密钥,对msg进行解密。从第
1个字节开始的16个字节即为与服务器通信的密钥暂称为ServerKey。该密钥经常
变化。
在本次登录中,以后所有跟服务器的通信都用这个ServerKey为密钥进行加密和解
密。
四、 其它用户发来的加密消息的解密。
其它用户的发来的加密消息格式为:
BYTE b1;固定为0x0
BYTE b2;固定为0x3
BYTE b3;固定为0xA或0X2
BYTE salt; OICQ号加密用
DWORD EncodeOicqID;加密后的从高到低的oicq号。
DWORD seq;序号
BYTE msg[变长]

l 对方oicq号的解密。
将EncodeOicqID的4个字节分别与salt进行异或操作,然后取反。
如salt = 0XA0, EncodeOicqID = 0X 5F5EBD1F。
//分别进行异或操作
0X 5F5EBD1F XOR 0XA0A0A0A0 = 0X FFFE1DBF
//再取反
NOT 0X FFFE1DBF = 0X1E240,转为10进制就是123456。因此对方的oicq号为123
456。
l 消息的解密。
先合成一个20字节的口令。前4个字节为从高到低的二进制对方的oicq号。后16个
字节为服务器发来的ServerKey。ServerKey的来源见第三节。
如对方的oicq号为123456,20字节的口令为
00 01 E2 40 + 16字节的ServerKey。
用口令算法对这20字节的口令进行计算,得16个字节的密钥,就可以解开对方发
来的消息。
五、 发给其它用户消息的加密
在登录后,服务器会通知好友的IP地址和端口,以及一个16个字节的密钥。就是
当前的OICQ号加对方16个字节ServerKey通过CalcPass的计算结果。
向对方发送消息时,只要用这16个字节进行加密即可。
dW 登录 | 注册 IBM developerWorks® 技术主题 软件下载 社区 技术讲座 搜索 developerWorks 打印本页面用电子邮件发送本页面新浪微博人人网腾讯微博搜狐微博网易微博DiggFacebookTwitterDeliciousLinked In developerWorks 中国技术主题Java technology文档库 在 Java 应用程序中访问 USB 设备 介绍 USB、jUSB 和 JSR-80 Java 平台一直都以其平台无关性自豪。虽然这种无关性有许多好处,但是它也使得编写与硬件交互的 Java 应用程序的过程变得相当复杂。在本文中,研究科学家蒋清野讨论了两个项目,它们通过提供使Java 应用程序可以使用 USB 设备的 API 而使这个过程变得更容易。虽然这两个项目仍然处于萌芽状态,但是它们都显示了良好的前景,并已经成为一些实用应用程序的基础。 1 评论: 蒋清野 (qjiang@ieee.org), 研究科学家, HappyFox Engineering Solutions 2003 年 10 月 25 日 + 内容 在 IBM Bluemix 云平台上开发并部署您的下一个应用。 现在就开始免费试用 通用串行总线(Universal Serial Bus USB)规范的第一个版本发表于 1996年 1月。因为它的低成本、高数据传输率、使用容易和灵活性,USB 在计算机行业里获得了广泛接受。今天,许多周边设备和装置都是通过 USB 接口连接到计算机上的。目前,大多数一般用途的操作系统都提供了对 USB 设备的支持,并且用 C 或者 C++ 可以相对容易地开发访问这些外设的应用程序。不过,Java 编程语言在设计上对硬件访问提供的支持很少,所以编写与 USB 设备交互的应用程序是相当困难的。 IBM 的 Dan Streetman 最早开始了在 Java 语言中提供对 USB 设备的访问的努力。2001年,他的项目通过 Java 规范请求(Java Specification Request,JSR)过程被接受为 Java 语言的候选扩展标准。这个项目现在称为 JSR-80 并且指定了官方包 javax.usb 。同时,在 2000年 6月,Mojo Jojo 和 David Brownell 在 SourceForge 开始了 jUSB 项目。这两个项目都开发出了 Linux 开发人员可以使用的包,尽管它们都还很不完善。这两个项目也都开始试图向其他操作系统上的 Java 应用程序提供对 USB 设备的访问,尽管它们都还没有开发出可以使用的包(参阅 参考资料 中有关本文中讨论的这两个项目及其他项目的资料)。 在本文中,将对 jUSB 和 JSR-80 项目作一个简要介绍,不过,我们首先要看一下 USB 协议的具体细节,这样您就可以理解这两个项目是如何与 USB 设备交互的。我们还将提供代码片段以展示如何用这两个项目的 API 访问 USB 设备。 USB 介绍 1994年,一个由四个行业伙伴(Compaq、Intel、Microsoft 和 NEC)组成的联盟开始制定 USB 协议。该协议最初的目的是将 PC 与电话相连并提供容易扩展和重新配置的 I/O 接口。1996年 1月,发表了 USB 规范的第一个版本,1998年 9月发表了后续版本(版本 1.1)。这个规范允许 127台设备同时连接到一起,总的通信带宽限制为 12 Mbps。后来,又有三个成员(Hewlett-Packard、Lucent 和 Philips)加入了这个联盟。2000年 4月,发表了 USB 规范的 2.0版本,它支持高达 480 Mbps 的传输率。今天,USB 在高速(视频、图像、储存)和全速(音频、宽带、麦克风)数据传输应用中起了关键作用。它还使各种低速设备(键盘、鼠标、游戏外设、虚拟现实外设)连接到 PC 上。 USB 协议有严格的层次结构。在所有 USB 系统中,只有一个主设备,到主计算机的的 USB 接口称为 主控器(host controller)。主控器有两个标准――开放主控器接口(Compaq 的 Open Host Controller Interface,OHCI)和通用主控器接口(Intel 的 Universal Host Controller Interface,UHCI)。这两个标准提供了同样的能力,并可用于所有的 USB 设备,UHCI 的硬件实现更简单一些,但是需要更复杂的设备驱动程序(因而 CPU 的负荷更大一些)。 USB 物理互连是分层的星形拓朴,最多有七层。一个 hub 是每个星形的中心,USB 主机被认为是 root hub。每一段连线都是 hub 与 USB 设备的点对点连接,后者可以是为系统提供更多附加点的另一个 hub,也可以是一个提供功能的某种设备。主机使用主/从协议与 USB 设备通信。这种方式解决了包冲突的问题,但是同时也阻止了附加的设备彼此建立直接通信。 所有传输的数据都是由主控器发起的。数据从主机流向设备称为 下行(downstream)或者 输出(out)传输,数据从设备流向主机称为 上 行(upstream)或者 输入(in)传输。数据传输发生在主机和 USB 设备上特定的 端点(endpoint) 之间,主机与端点之间的数据链接称为 管道(pipe)。 一个给定的 USB 设备可以有许多个端点,主机与设备之间数据管道的数量与该设备上端点的数量相同。一个管道可以是单向或者是双向的,一个管道中的数据流与所有其他管道中的数据流无关。 USB 网络中的通信可以使用下面四种数据传输类型中的任意一种: 控制传输:这些是一些短的数据包,用于设备控制和配置,特别是在设备附加到主机上时。 批量传输:这些是数量相对大的数据包。像扫描仪或者 SCSI 适配器这样的设备使用这种传输类型。 中断传输:这些是定期轮询的数据包。主控器会以特定的间隔自动发出一个中断。 等时传输:这些是实时的数据流,它们对带宽的要求高于可靠性要求。音频和视频设备一般使用这种传输类型。 像串行端口一样,计算机上每一个 USB 端口都由 USB 控制器指定了一个惟一的标识数字(端口 ID)。当 USB 设备附加到 USB 端口上时,就将这个 惟一端口 ID 分配给这台设备,并且 USB 控制器会读取 设备描述符。设备描述符包括适用于该设备的全局信息、以及设备的 配置信息。配置定义了一台 USB 设备的功能和 I/O 行为。一台 USB 设备可以有一个或者多个配置,这由它们相应的配置描述符所描述。每一个配置都有一个或者多个 接口,它可以视为一个物理通信渠道 ;每一个接口有零个或者多个端点,它可以是数据提供者或者数据消费者,或者同时具有这两种身份。接口由接口描述符描述,端点由端点描述符描述。并且一台 USB 设备可能还有字符串描述符以提供像厂商名、设备名或者序列号这样的附加信息。 正如您所看到的,像 USB 这样的协议为使用 Java 这种强调平台和硬件无关性的语言的开发人员提出了挑战。现在让我们看两个试图解决这个问题的项目。 回页首 jUSB API jUSB 项目是由 Mojo Jojo 和 David Brownell 于 2000年 6月创立的。其目标是提供一组免费的、在 Linux 平台上访问 USB 设备的 Java API。这个 API 是按照 Lesser GPL (LGPL)条款发表的,这意味着您可以在专有和免费软件项目中使用它。这个 API 提供了对多个物理 USB 设备的多线程访问,并支持本机和远程设备。具有多个接口的设备可以同时被多个应用程序(或者设备驱动程序)所访问,其中每一个应用程序(或者设备驱动程序)都占据一个不同的接口。该 API 支持控制传输、批量传输和中断传输,不支持等时传输,因为等时传输用于媒体数据(如音频和视频),JMF API 已经在其他标准设备驱动程序上对此提供了很好的支持(参阅 参考资料)。当前,该 API 可以在具有 Linux 2.4 核心或者以前的 2.2.18 核心的 GNU/Linux 版本上工作。因此可支持大多数最新的版本,例如,该 API 可以在没有任何补丁或者升级的 Red Hat 7.2 和 9.0 上工作。 jUSB API 包括以下包: usb.core : 这个包是 jUSB API 的核心部分。它使得 Java 应用程序可以从 USB 主机访问 USB 设备。 usb.linux : 这个包包含 usb.core.Host 对象的 Linux 实现、bootstrapping 支持和其他可以提升 Linux USB 支持的类。这个实现通过虚拟 USB 文件系统( usbdevfs )访问 USB 设备。 usb.windows : 这个包包含 usb.core.Host 对象的 Windows 实现、bootstrapping 支持和其他可以提升 Windows USB 支持的类。这个实现仍然处于非常初级的阶段。 usb.remote : 这个包是 usb.core API 的远程版本。它包括一个 RMI proxy 和一个 daemon 应用程序,它让 Java 应用程序可以访问远程计算机上的 USB 设备。 usb.util : 这个包提供了一些有用的实用程序,可以将 firmware下载到 USB 设备上、将 USB 系统的内容转储到 XML 中、以及将只有 bulk I/O 的 USB 设备工具转换成一个套接字(socket)。 usb.devices : 这个可选包收集了用 jUSB API 访问不同 USB 设备的 Java 代码,包括柯达数码相机和 Rio 500 MP3 播放器。这些 API 经过特别编写以简化访问特定 USB 设备的过程,并且不能用于访问其他设备。这些 API 是在 usb.core API 之上构建的,它们可以工作在所有支持 jUSB 的操作系统上。 usb.view : 这个可选包提供了基于 Swing 的 USB 树简单浏览器。它是一个展示 jUSB API 应用的很好的示例程序。 尽管 usb.core.Host 对象的实现对于不同的操作系统是不同的,但是 Java 程序员只需要理解 usb.core 包就可以用 jUSB API 开始应用程序的开发。表 1 列出了 usb.core 的接口和类,Java 程序员应该熟悉它们: 表 1. jUSB 中的接口和类 接口 说明 Bus 将一组 USB 设备连接到 Host 上 Host 表示具有一个或者多个 Bus 的 USB 控制器 类 说明 Configuration 提供对设备所支持的 USB 配置的访问,以及对与该配置关联的接口的访问 Descriptor 具有 USB 类型的描述符的实体的基类 Device 提供对 USB 设备的访问 DeviceDescriptor 提供对 USB 设备描述符的访问 EndPoint 提供对 USB 端点描述符的访问、在给定设备配置中构造设备数据输入或者输出 HostFactory 包含 bootstrapping 方法 Hub 提供对 USB hub 描述符以及一些 hub 操作的访问 Interface 描述一组端点,并与一个特定设备配置相关联 PortIdentifier 为 USB 设备提供稳定的字符串标识符,以便在操作和故障诊断时使用 用 jUSB API 访问一台 USB 设备的正常过程如下: 通过从 HostFactory 得到 USB Host 进行 Bootstrap。 从 Host 访问 USB Bus ,然后从这个 Bus 访问 USB root hub(即 USB Device )。 得到 hub 上可用的 USB 端口数量,遍历所有端口以找到正确的 Device 。 访问附加到特定端口上的 USB Device 。可以用一台 Device 的 PortIdentifier 直接从 Host 访问它,也可以通过从 root hub 开始遍历 USB Bus 找到它。 用 ControlMessage 与该 Device 直接交互,或者从该 Device 的当前 Configuration 中要求一个 Interface, 并与该 Interface 上可用的 Endpoint 进行 I/O 。 清单 1 展示了如何用 jUSB API 获得 USB 系统中的内容。这个程序编写为只是查看 root hub 上可用的 USB 设备,但是很容易将它改为遍历整个 USB 树。这里的逻辑对应于上述步骤 1 到步骤 4。 清单 1. 用 jUSB API 获得 USB 系统的内容 import usb.core.*; public class ListUSB { public static void main(String[] args) { try { // Bootstrap by getting the USB Host from the HostFactory. Host host = HostFactory.getHost(); // Obtain a list of the USB buses available on the Host. Bus[] bus = host.getBusses(); int total_bus = bus.length; // Traverse through all the USB buses. for (int i=0; i通讯 新浪微博 报告滥用 使用条款 第三方提示 隐私条约 浏览辅助 IBM 教育学院教育培养计划 IBM 创业企业全球扶持计划 ISV 资源 (英语) dW 中国每周时事通讯 选择语言: English 中文 日本語

16,472

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

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