简述电子邮件服务器的工作原理

简述电子邮件服务器的工作原理,第1张

电子邮件服务器工作原理:

1) 发件人用户代理撰写电子邮件,点击“发送邮件”,发送邮件的 工作交个用户代理来完成,用户代理用SMTP协议发给发送方服务器,用户代理充当SMTP客户,发送服务器充当SMTP服务器;发送之前建立TCP连接;

2) SMTP服务器收到客户端发送来的邮件,将其放到邮件缓冲队 列中,等待发送到接收发的服务器中;

3) 发送服务器的SMTP客户端与接收服务器的SMTP服务器建立 TCP连接,然后把缓冲队列中的邮件发到目的服务器;

4) 运行在接收方服务器的SMTP服务器进程收到邮件后,把邮件 发如收件人信箱,等待读取;

5) 收件人打开计算机,运行客户端软件,使用POP3(IMAP)协 议读取邮件。

邮件服务器采用的是客户端服务器模式,其工作过程如下图所示:

(说明:一个电子邮件系统有三个主要构件组成:用户代理(客户端应用程序),邮件服务器,邮件发送和邮件接收协议)

图像数据在数据库内部的存储原理:
XML 是文本型的数据交换结构,对于字符类型的文本交换非常的方便,实际工作中我们往往需要通过 XML 将二进制格式的图形图像信息数据进行数据交换。本文从介绍 BASE64 编码的原理入手,通过采用 C 语言编写 DB2 的嵌入存储过程,实现了在数据库内存中将文本格式的文件到二进制 BLOB 字段之间的转换,并且就性能优化等提出若干建议,该设计思路和程序可以广泛的应用到图像图形数据在 XML 的存储和转换。
--------------------------------------------------------------------------------
回页首
XML 存储图形图像的基本原理
XML 作为一种非常广泛的数据交换的载体被广泛的应用到了各行各业的数据交换中。对于图形图像数据的转换,需要采用 Base64 编码将二进制格式的图形图像信息转换成文本格式再进行传输。
Base64 编码转换的思想是通过 64 个 ASCII 字符码对二进制数据进行重新编码组合,即将需要转换的数据每三个字节(24 位)为一组,再将这 24 位数据按每组 6 位进行重新划分,在每组的最高 2 位填充 0 最终成一个完整的 8 位字节。如果所要编码的数据的字节数不是 3 的整数倍,需要在最后一组数据填充 1 到 2 个字节的 0 字节。例如:我们对 ABC 进行 BASE64 的编码,ABC 的编码值:A(65), B(66), C(67)。再取二进制 A(01000001)B(01000010)C(01000011)连接起来构成 010000010100001001000011,然后按 6 位为单位分成 4 个数据块并在最高位填充两个 0 后形成 4 个字节的编码后的值(00010000)(00010100)(00001001)(00000011)。再将 4 个字节的数据转换成十进制数为(16)(20)(19)(3)。最后根据 BASE64 给出的 64 个基本字符表,查出对应的 ASCII 码字符(Q)(U)(J)(D)。这里的值实际就是数据在字符表中的索引。
BASE64 字符表:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789。
某项目的数据交换采用 XML 的为介质,XML 的结构包括个人基本信息:姓名、性别、相片等信息,其中相片信息是采用经过 BASE64 函数转换后的文本型数据,图像图形信息通过 BASE64 进行数据转换后,形成文本格式的数据类型,再将相应的数据存放到 XML 中,最终形成可供交换的文本型的 XML 数据结构。
XML 的数据结构如下所示:
<xml version=”10” encoding=”UTF-8” >
<HeadInfo>
<TotalNum>10<TotalNum>
<TransDate>2007-10-18</TransDate>
</HeadInfo>
<Data>
<Name> 张三 </Name>
<Sex> 男 </Sex>
<Photo>/9j/4AAQSkZJRgABAQAAAQABAAD</Photo>
<Data>
--------------------------------------------------------------------------------
回页首
相片数据在 DB2 嵌入式 C 程序的实现方法
该项目要求能够在 DB2 数据库中将相片数据存储为二进制 BLOB 格式。我们采用 DATASTAGE 进行 XML 数据加载,将 XML 中的姓名、性别等基本数据项加载到相应的字段,其中文本型的相片数据则加载到 CLOB 字段中,再按照 BASE64 的编码规则进行逆向转码,整个数据流程如下图所示:
图 1 相片存储流程图
用户的相片每天的更新数据为 30 万条,而且每个相片的平均大于 32KB,为了获得最佳的数据库性能,选择采用 C 存储过程的方式开发了 BASE64 的转换函数。每次函数读取存储在 CLOB 字段的文本格式数据全部存储到内存中,并且通过 decode 函数在内存中进行转码,转码后再存入数据库中。
程序的清单 1 是逐行读取 CLOB 字段,并且调用 decode 函数进行转码;程序的清单 2 是 decode 函数的关键性代码。完整的程序见源代码下载部分。
清单 1 读入 CLOB,写入 BLOB 字段

EXEC SQL BEGIN DECLARE SECTION;
SQL TYPE IS CLOB(100 K) clobResume; //CLOB 结构体变量
SQL TYPE IS BLOB(100 K) blobResume; //BLOB 结构体变量
sqlint16 bobind;
sqlint16 lobind;
sqlint16 cobind;
sqlint32 idValue;

EXEC SQL END DECLARE SECTION;
int clob2bin(void)
{
// 声明 SQLCA 结构
struct sqlca sqlca;
int charNb;
int lineNb;
long n;
n=0;

// 定义数据库游标
EXEC SQL DECLARE c1 CURSOR WITH HOLD FOR
SELECT czrkxp_a
FROM CZRK_blob for update;
EXEC SQL OPEN c1;

// 活动 CLOB 字段的信息,已经 CLOB 字段的大小
EXEC SQL FETCH c1 INTO :clobResume:cobind;
// 循环读取 CLOB 字段,并且调用 DECODE 转码函数
while (sqlcasqlcode != 100)
{
if (cobind < 0)
{
printf(“ NULL LOB indicated\n”);
}
else
{
n++;
decode(); // 文本格式到二进制流的转码函数
printf(“\nCurrent Row =%ld”,n);
// 数据写入 BLOB 字段
EXEC SQL update czrk_blob set czrkxp_blob = :blobResume
where current of c1; ;
// 提交事务
EXEC SQL COMMIT;
}
EXEC SQL FETCH c1 INTO :clobResume:cobind ;
}
// 关闭游标
EXEC SQL CLOSE c1;
EXEC SQL COMMIT;
return 0;
}
清单 2 文本文件到二进制文件的转换

void decode( void )
{
unsigned char in[4], out[3], v;
int I, len;
long j,k;
j = -1;
k=0;
// 将读入 CLOB 结构体变量的数据进行转换
while( j < clobResumelength){
for( len = 0, I = 0; I < 4 && ( j < clobResumelength ); i++ ) {
v = 0;
while((j < clobResumelength) && v == 0 ) {
j++;
v = (unsigned char) clobResumedata[j];
v = (unsigned char) ((v < 43 || v > 122) 0 : cd64[ v – 43 ]);
if( v ) {
v = (unsigned char) ((v == ‘$’) 0 : v – 61);
}
}
if( j < clobResumelength ) {
len++;
if( v ) {
in[ I ] = (unsigned char) (v – 1);
}
}
else {
in[i] = 0;
}
}
if( len ) {
decodeblock( in, out );
// 写入到 BLOB 结构体变量中
for( I = 0; I < len – 1; i++ ) {
blobResumedata[k] = out[i];
k++;
}
}
}
blobResumelength= k;
}
--------------------------------------------------------------------------------
回页首
数据的转换效率和优化建议
在 IBM P570 数据库服务器上运行,该程序的运行效率非常高,先后进行了几个数量级的测试,最终平均测试的转换效率为:每 1 万笔数据记录,转换的效率 55 秒,即 182 条 / 秒。值得注意的是,整个转换过程占用 CPU 的量并不特别大,主要的性能瓶颈在磁盘阵列中。
以后可以进一步在以下方面进行调优,确保程序转换的效率更高:
1)采用多进程调用的方式,以获得更高的并发数量;
2)采用每 10 次或者 100 次提交事务的方式,减少访问磁盘的次数;
3)将 CLOB 和 BLOB 分别放置在不同的表空间上,并且将表空间分布在在多个磁盘上,获得最佳的磁盘访问速度。

服务器说白了就是 一台安装了对应处理程序的普通电脑
一般网游,服务器上只是进行数据的处理,并不是会创建地图,比如你进行一个攻击 *** 作,把数据传送到服务器,服务器进行计算(伤害多少,是否暴击,最终伤害,命中了谁,扣血),把这些数据返回客户端,客户端根据得到的数据进行视觉显示
单机游戏和网游类似,但是在客户端内内置了一个服务器,你的数据在本机服务器进行计算,并返回本机客户端进行显示,联机时,队友的数据传送到你本机的服务器进行计算,然后返回队友的客户端进行显示
简单说,普通电脑上 安装服务器软件 后,这台电脑就可以是一个服务器
你要把客户端和服务端分开看,服务器就是处理数据的软件。常说的游戏程序(客户端)就是显示数据的软件。
网游客户端在本地,服务端在官方服务器上
单机游戏,客户端在本地,服务端包含在客户端内

无盘工作站是由网卡的启动芯片Bootrom,以不同的形式向服务器发出启动请求信号,服务器收到后,根据不同的机制,向工作站发送启动数据,工作站下载完启动数据后,系统控制权由Boot ROM转到内存中的某些特定区域,并引导 *** 作系统

客户端开机后, 在 TCP/IP Bootrom 获得控制权之前先做自我测试。 Bootprom 送出 BOOTP/DHCP 要求以取得 IP。

如果服务器收到客户端所送出的要求, 就会送回 BOOTP/DHCP 回应,内容包括:客户端的 IP 地址,预设网关,及开机影像文件。否则, 服务器会忽略这个要求。

Bootprom 由 TFTP 通讯协议从服务器下载开机镜像文件。TFTP协议为Trivial File Transfer Protocol缩写,意为:简单文件传输协议,TFTP可以看成一个简化了的FTP,主要的区别是没有用户权限管理的功能,也就是说TFTP不需要认证客户端的权限,这样远程启动的客户机在启动一个完整的 *** 作系统之前就可以通过TFTP下载启动映象文件,而不需要证明自己是合法的用户。

客户机通过这个开机镜像文件开机,这个开机文件可以只是单纯的开机程序也可以是 *** 作系统。开机镜像文件将包含 kernel loader 及压缩过的 kernel, 此 kernel 将支持NTFS root系统。并将开机镜像文件在工作站内存模拟成磁盘,从这个模拟磁盘启动。

PXE无盘启动要经过下面的几个过程

客户机自检,加载PXE BOOT ROM

PXE 请求 DHCP

服务器分配IP

客户机获取IP建立TCP/IP连接

通过 TFTP 获取开机镜像

加载开机镜像,转交启动控制权给Boot Loader

Boot Loader引导 *** 作系统

另外再附上一个易游无盘的启动原理示意图,可能更容易理解一些


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zz/13359532.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-21
下一篇 2023-07-21

发表评论

登录后才能评论

评论列表(0条)

保存