[引用]~~我们的考试题,我怎么都想不出来为什么答案是这个~帮帮我吧~~ 在线等!

CSDN专家门诊C/C++ C语言问题
回复 | 推荐 | 收藏 | 专题 | 公告 | 管理 | 关闭窗口
主  题: ~~我们的考试题,我怎么都想不出来为什么答案是这个~帮帮我吧~~ 在线等!
作  者: diege2002 (卡卡)
等  级:
信 誉 值: 100
所属论坛: C/C++ C语言
问题点数: 100
回复次数: 48
发表时间: 2006-4-27 20:58:50
有一个函数
low_to_up(char in)
{
char ch;
if(in>=’a’ && in<=’z’)
ch=in-‘a’+’A’;
else
return (ch);
}
输入d,会输出什么?
A:D;
B:error:(原文我忘了,中文意思是:)返回值类型未指定
C:error(同上)else没有if相匹配
答案是A
可是为什么呀?我怎么想都不明白,执行if后,又没有返回值!
而且,函数没有返回值,默认返回int呀,怎么会是’D’呢?
 
 

关于Msocache文件夹

关于Msocache文件夹


系统中总是在盘中出现MSOCache这样一个隐藏的文件夹还很大,我们来看看这个文件夹的产生与作用。

这是Offiece的本地安装源 (Msocache)。“本地安装源”是一种安装功能,它将安装源文件从 Microsoft Office 2003 安装媒体(例如 Office 2003 光盘)复制到 Msocache 文件夹。该文件夹是您的本地硬盘上的一个隐藏文件夹。

如果满足以下条件,安装源文件将被从安装媒体复制到您的本地硬盘上的 Msocache 文件夹: • 其中一个可用硬盘驱动器具有 1.5 GB 以上的可用磁盘空间。
• 具有足够空间的硬盘不是可移动驱动器或网络驱动器。
如果您要删除 Msocache 文件夹,可以在 Office 安装期间或 Office 安装之后执行此操作。删除这些文件将节省大约 270 MB 的硬盘空间。删除 Msocache 文件夹后,您可能必须提供安装媒体才能完成前面列举的安装操作。

注意:MSOCACHE 文件夹不总是位于可用空间最多的硬盘驱动器上。如果您计算机的 NTFS 驱动器至少具有 1.5 GB 的可用空间,MSOCACHE 文件夹将位于该 NTFS 驱动器中。

买不起手提电脑,火了!老子自己做不行吗?

买不起手提电脑,火了!老子自己做不行吗?

先看一下这款木头PC的配置和作品特点:
CPU是AMD Athlon XP 2500+
主板是MSI KT3 Ultra
显卡是ATI Radeon 9600 128MB
内存是512MB DDR333
光存储是Steatlthed DVD-ROM Drive
显示器是14英寸LCD
硬盘是Seagate 40G
电源是250W 802.11g NIC
无线网卡
内置声卡
木制键盘
数控音箱
酷炫效果
重量:17磅
尺寸:18.5×19.5×5.25(英寸)
改造开始了。第一件事情自然是为系统找一些资源,机箱其实不算小, 因此主板和键盘将会是全尺寸的,另外我选择了一款廉价的14英寸LCD, 它将会采用木制的外观
开始做显示器

BitTorrent Community Forum-Protocol

BitTorrent is a protocol for distributing files. It identifies content by URL and is designed to integrate seamlessly with the web. Its advantage over plain HTTP is that when multiple downloads of the same file happen concurrently, the downloaders upload to each other, making it possible for the file source to support very large numbers of downloaders with only a modest increase in its load.

A BitTorrent file distribution consists of these entities:

  • An ordinary web server
  • A static ‘metainfo’ file
  • A BitTorrent tracker
  • An ‘original’ downloader
  • The end user web browsers
  • The end user downloaders

There are ideally many end users for a single file.

To start serving, a host goes through the following steps:

  1. Start running a tracker (or, more likely, have one running already).
  2. Start running an ordinary web server, such as apache, or have one already.
  3. Associate the extension .torrent with mimetype application/x-bittorrent on their web server (or have done so already).
  4. Generate a metainfo (.torrent) file using the complete file to be served and the URL of the tracker.
  5. Put the metainfo file on the web server.
  6. Link to the metainfo (.torrent) file from some other web page.
  7. Start a downloader which already has the complete file (the ‘origin’).

To start downloading, a user does the following:

  1. Install BitTorrent (or have done so already).
  2. Surf the web.
  3. Click on a link to a .torrent file.
  4. Select where to save the file locally, or select a partial download to resume.
  5. Wait for download to complete.
  6. Tell downloader to exit (it keeps uploading until this happens).

The connectivity is as follows:

  • The web site is serving up static files as normal, but kicking off the BitTorrent helper app on the clients.
  • The tracker is receiving information from all downloaders and giving them random lists of peers. This is done over HTTP or HTTPS.
  • Downloaders are periodically checking in with the tracker to keep it informed of their progress, and are uploading to and downloading from each other via direct connections. These connections use the BitTorrent peer protocol, which operates over TCP.
  • The origin is uploading but not downloading at all, since it has the entire file. The origin is necessary to get the entire file into the network. Often for popular downloads the origin can be taken down after a while since several downloads may have completed and been left running indefinitely.

Metainfo file and tracker responses are both sent in a simple, efficient, and extensible format called bencoding (pronounced ‘bee encoding’). Bencoded messages are nested dictionaries and lists (as in Python), which can contain strings and integers. Extensibility is supported by ignoring unexpected dictionary keys, so additional optional ones can be added later.

Bencoding is done as follows:

  • Strings are length-prefixed base ten followed by a colon and the string. For example 4:spam corresponds to ‘spam’.
  • Integers are represented by an ‘i’ followed by the number in base 10 followed by an ‘e’. For example i3e corresponds to 3 and i-3e corresponds to -3. Integers have no size limitation. i-0e is invalid. All encodings with a leading zero, such as i03e , are invalid, other than i0e , which of course corresponds to 0.
  • Lists are encoded as an ‘l’ followed by their elements (also bencoded) followed by an ‘e’. For example l4:spam4:eggse corresponds to [‘spam’, ‘eggs’].
  • Dictionaries are encoded as a ‘d’ followed by a list of alternating keys and their corresponding values followed by an ‘e’. For example, d3:cow3:moo4:spam4:eggse corresponds to {’cow’: ‘moo’, ‘spam’: ‘eggs’} and d4:spaml1:a1:bee corresponds to {’spam’: [‘a’, ‘b’]} . Keys must be strings and appear in sorted order (sorted as raw strings, not alphanumerics).

Metainfo files are bencoded dictionaries with the following keys:

announce

The URL of the tracker.

info

This maps to a dictionary, with keys described below.

The name key maps to a string which is the suggested name to save the file (or directory) as. It is purely advisory.

piece length maps to the number of bytes in each piece the file is split into. For the purposes of transfer, files are split into fixed-size pieces which are all the same length except for possibly the last one which may be truncated. Piece length is almost always a power of two, most commonly 2 18 = 256 K (BitTorrent prior to version 3.2 uses 2 20 = 1 M as default).

pieces maps to a string whose length is a multiple of 20. It is to be subdivided into strings of length 20, each of which is the SHA1 hash of the piece at the corresponding index.

There is also a key length or a key files , but not both or neither. If length is present then the download represents a single file, otherwise it represents a set of files which go in a directory structure.

In the single file case, length maps to the length of the file in bytes.

For the purposes of the other keys, the multi-file case is treated as only having a single file by concatenating the files in the order they appear in the files list. The files list is the value files maps to, and is a list of dictionaries containing the following keys:

length The length of the file, in bytes. path A list of strings corresponding to subdirectory names, the last of which is the actual file name (a zero length list is an error case).

In the single file case, the name key is the name of a file, in the muliple file case, it’s the name of a directory.

Tracker queries are two way. The tracker receives information via HTTP GET parameters and returns a bencoded message. Note that although the current tracker implementation has its own web server, the tracker could run very nicely as, for example, an apache module.

Tracker GET requests have the following keys:

info_hash

The 20 byte sha1 hash of the bencoded form of the info value from the metainfo file. Note that this is a substring of the metainfo file. This value will almost certainly have to be escaped.

peer_id

A string of length 20 which this downloader uses as its id. Each downloader generates its own id at random at the start of a new download. This value will also almost certainly have to be escaped.

ip

An optional parameter giving the IP (or dns name) which this peer is at. Generally used for the origin if it’s on the same machine as the tracker.

port

The port number this peer is listening on. Common behavior is for a downloader to try to listen on port 6881 and if that port is taken try 6882, then 6883, etc. and give up after 6889.

uploaded

The total amount uploaded so far, encoded in base ten ascii.

downloaded

The total amount downloaded so far, encoded in base ten ascii.

left

The number of bytes this peer still has to download, encoded in base ten ascii. Note that this can’t be computed from downloaded and the file length since it might be a resume, and there’s a chance that some of the downloaded data failed an integrity check and had to be re-downloaded.

event

This is an optional key which maps to started , completed , or stopped (or empty, which is the same as not being present). If not present, this is one of the announcements done at regular intervals. An announcement using started is sent when a download first begins, and one using completed is sent when the download is complete. No completed is sent if the file was complete when started. Downloaders send an announcement using ‘stopped’ when they cease downloading.

Tracker responses are bencoded dictionaries. If a tracker response has a key failure reason , then that maps to a human readable string which explains why the query failed, and no other keys are required. Otherwise, it must have two keys: interval , which maps to the number of seconds the downloader should wait between regular rerequests, and peers . peers maps to a list of dictionaries corresponding to peers, each of which contains the keys peer id , ip , and port , which map to the peer’s self-selected ID, IP address or dns name as a string, and port number, respectively. Note that downloaders may rerequest on nonscheduled times if an event happens or they need more peers.

If you want to make any extensions to metainfo files or tracker queries, please coordinate with Bram Cohen to make sure that all extensions are done compatibly.

BitTorrent’s peer protocol operates over TCP. It performs efficiently without setting any socket options.

Peer connections are symmetrical. Messages sent in both directions look the same, and data can flow in either direction.

The peer protocol refers to pieces of the file by index as described in the metainfo file, starting at zero. When a peer finishes downloading a piece and checks that the hash matches, it announces that it has that piece to all of its peers.

Connections contain two bits of state on either end: choked or not, and interested or not. Choking is a notification that no data will be sent until unchoking happens. The reasoning and common techniques behind choking are explained later in this document.

Data transfer takes place whenever one side is interested and the other side is not choking. Interest state must be kept up to date at all times – whenever a downloader doesn’t have something they currently would ask a peer for in unchoked, they must express lack of interest, despite being choked. Implementing this properly is tricky, but makes it possible for downloaders to know which peers will start downloading immediately if unchoked.

Connections start out choked and not interested.

When data is being transferred, downloaders should keep several piece requests queued up at once in order to get good TCP performance (this is called ‘pipelining’.) On the other side, requests which can’t be written out to the TCP buffer immediately should be queued up in memory rather than kept in an application-level network buffer, so they can all be thrown out when a choke happens.

The peer wire protocol consists of a handshake followed by a never-ending stream of length-prefixed messages. The handshake starts with character ninteen (decimal) followed by the string ‘BitTorrent protocol’. The leading character is a length prefix, put there in the hope that other new protocols may do the same and thus be trivially distinguishable from each other.

All later integers sent in the protocol are encoded as four bytes big-endian.

After the fixed headers come eight reserved bytes, which are all zero in all current implementations. If you wish to extend the protocol using these bytes, please coordinate with Bram Cohen to make sure all extensions are done compatibly.

Next comes the 20 byte sha1 hash of the bencoded form of the info value from the metainfo file. (This is the same value which is announced as info_hash to the tracker, only here it’s raw instead of quoted here). If both sides don’t send the same value, they sever the connection. The one possible exception is if a downloader wants to do multiple downloads over a single port, they may wait for incoming connections to give a download hash first, and respond with the same one if it’s in their list.

After the download hash comes the 20-byte peer id which is reported in tracker requests and contained in peer lists in tracker responses. If the receiving side’s peer id doesn’t match the one the initiating side expects, it severs the connection.

That’s it for handshaking, next comes an alternating stream of length prefixes and messages. Messages of length zero are keepalives, and ignored. Keepalives are generally sent once every two minutes, but note that timeouts can be done much more quickly when data is expected.

All non-keepalive messages start with a single byte which gives their type. The possible values are:

  • 0 – choke
  • 1 – unchoke
  • 2 – interested
  • 3 – not interested
  • 4 – have
  • 5 – bitfield
  • 6 – request
  • 7 – piece
  • 8 – cancel

‘choke’, ‘unchoke’, ‘interested’, and ‘not interested’ have no payload.

‘bitfield’ is only ever sent as the first message. Its payload is a bitfield with each index that downloader has sent set to one and the rest set to zero. Downloaders which don’t have anything yet may skip the ‘bitfield’ message. The first byte of the bitfield corresponds to indices 0 – 7 from high bit to low bit, respectively. The next one 8-15, etc. Spare bits at the end are set to zero.

The ‘have’ message’s payload is a single number, the index which that downloader just completed and checked the hash of.

‘request’ messages contain an index, begin, and length. The last two are byte offsets. Length is generally a power of two unless it gets truncated by the end of the file. All current implementations use 2 15 , and close connections which request an amount greater than 2 17 .

‘cancel’ messages have the same payload as request messages. They are generally only sent towards the end of a download, during what’s called ‘endgame mode’. When a download is almost complete, there’s a tendency for the last few pieces to all be downloaded off a single hosed modem line, taking a very long time. To make sure the last few pieces come in quickly, once requests for all pieces a given downloader doesn’t have yet are currently pending, it sends requests for everything to everyone it’s downloading from. To keep this from becoming horribly inefficient, it sends cancels to everyone else every time a piece arrives.

‘piece’ messages contain an index, begin, and piece. Note that they are correlated with request messages implicitly. It’s possible for an unexpected piece to arrive if choke and unchoke messages are sent in quick succession and/or transfer is going very slowly.

Downloaders generally download pieces in random order, which does a reasonably good job of keeping them from having a strict subset or superset of the pieces of any of their peers.

Choking is done for several reasons. TCP congestion control behaves very poorly when sending over many connections at once. Also, choking lets each peer use a tit-for-tat-ish algorithm to ensure that they get a consistent download rate.

The choking algorithm described below is the currently deployed one. It is very important that all new algorithms work well both in a network consisting entirely of themselves and in a network consisting mostly of this one.

There are several criteria a good choking algorithm should meet. It should cap the number of simultaneous uploads for good TCP performance. It should avoid choking and unchoking quickly, known as ‘fibrillation’. It should reciprocate to peers who let it download. Finally, it should try out unused connections once in a while to find out if they might be better than the currently used ones, known as optimistic unchoking.

The currently deployed choking algorithm avoids fibrillation by only changing who’s choked once every ten seconds. It does reciprocation and number of uploads capping by unchoking the four peers which it has the best download rates from and are interested. Peers which have a better upload rate but aren’t interested get unchoked and if they become interested the worst uploader gets choked. If a downloader has a complete file, it uses its upload rate rather than its download rate to decide who to unchoke.

For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of it’s upload rate (if interested, it counts as one of the four allowed downloaders.) Which peer is optimistically unchoked rotates every 30 seconds. To give them a decent chance of getting a complete piece to upload, new connections are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation.

教育部发言人激怒网友 要求教育部收回并道歉

教育部发言人激怒网友 要求教育部收回并道歉
出处:海峡都市报 | 2006-3-13 6:59:02 | 阅读 22463 次
1.好大学属于富人,老百姓别问津;2.大学教育是高消费,腰包没钱别进来;3.老百姓不懂教育,整天瞎嚷嚷;4.人民的观念有问题,需要转变。
本报讯 “当希望工程轰轰烈烈开展起来的时候,当全社会都被白芳礼感动的时候,教育部新闻发言人在答复两会代表和媒体时对国人说:穷人,你没钱就不要接受高等教育,因为你消费不起。”本周,网络上最热闹的话题之一莫过于教育部发言人王旭明针对两会代表们反映“上学贵”问题的答复而引起的争论。

  教育部发言人:“如果没钱就只能去小店”

  据新华社3月6日报道,教育部发言人王旭明根据两会期间代表们反映的“上学贵”的问题回复说:“人们对学费问题应当转变观念。在计划经济时代,孩子从小学上到大学花的钱很少,因为国家都给包了,但是在市场经济时代,形势已经发生变化。非义务教育阶段的教育已经成了家庭的一种消费,既然是消费,就要根据自己的经济、智力、实力来选择。北大、清华这些优质教育资源是有限的,自然比较贵,不是所有人都消费得起的。就好比逛市场买东西,如果有钱,可以去买1万元一套的衣服;如果没钱,就只能去小店,买100元一套的衣服穿。现在很多人不考虑自己实力如何,都想让孩子往好学校里挤,这是非理性的,也是形成 ‘上学贵’观念重要来由之一。”

  网友总结称,此话有四条主要信息:1.好大学属于富人,老百姓别问津;2.大学教育是高消费,腰包没钱别进来;3.老百姓不懂教育,整天瞎嚷嚷;4.人民的观念有问题,需要转变。

  网友:比喻荒谬得很教育部得收回

  王旭明的这一言论旋即引起了网友强烈反弹。

  网友南海表示,北大清华这些优质教育资源确实有限,但它们毕竟是属于中华人民共和国全体公民所有,它们的“贵”不应该是体现在钱上面,而应该体现在它们所面向的是全中国最优秀的考生这一点上。因为优质,所以哪怕再有钱,达不到最优秀的标准也别想进来。反过来讲,只要是国家需要的优秀人才,即使是身无分文,名牌大学的校门对他们也应该是永远敞开的。这才是教育部发言人应该说的话。

  还有网友指出:美国的“优质资源”哈佛大学,学生在注册时都要带上上一年父母的纳税表,全家收入在四万美元以下是免费的!即使不免费的学校也有各种不同类型的奖学金。有网友表示:教育部新闻发言人说的话、作的比喻,本身就荒谬得很,简直是扯淡。一定要让教育部收回这句话,并道歉!

责编:keso

BitTorrent 协议规范(BT协议集合)一 B

BitTorrent 协议规范(BT协议集合)一 A

 

Tracker 查询。Trakcer通过HTTPGET命令的参数来接收信息,而响应给对方(也就是下载者)的是经过bencoded编码的消息。注意,尽管当前的 tracker的实现需要一个web服务器,它实际上可以运行的更轻便一些,例如,作为apache的一个模块。

 

Tracker GET requests have the following keys:

 

发送给TrackerGET请求,包含以下关键字:

 

Info_hash

元文件中info部分的sha hash20字节长。这个字符创几乎肯定需要被转义(译注:在URL中,有些字符不能出现,必须通过unicode进行编码)

 

Peer_id

下载者的id,一个20字节长的字符串。每个下载者在开始一次新的下载之前,需要随机创建这个id。这个字符串通常也需要被转义。

 

Ip

一个可选的参数,给出了peerip地址(或者dns名称?)。通常用在origin身上,如果它和tracker在同一个机器上。

 

Port

peer所监听的端口。下载者通常在在 6881 端口上监听,如果该端口被占用,那么会一直尝试到 6889,如果都被占用,那么就放弃监听。

 

Uploaded

已经上载的数据大小,十进制表示。

 

Downloaded

已经下载的数据大小,十进制表示

 

Left

peer还有多少数据没有下载完,十进制表示。注意,这个值不能根据文件长度和已下载数据大小计算出来,因为很可能是断点续传,如果因为检查文件完整性失败而必须重新下载的时候,这也提供了一个机会。

 

Event

一个可选的关键字,值是startedcompted或者stopped之一(也可以为空,不做处理)。如果不出现该关键字,。在一次下载刚开始的时候,该值被设置为started,在下载完成之后,设置为completed。如果下载者停止了下载,那么该值设置为stopped

 

Tracker 的响应是用bencoded编码的字典。如果tracker的响应中有一个关键字failure reason,那么它对应的是一个字符串,用来解释查询失败的原因,其它关键字都不再需要了。否则,它必须有两个关键字:Interval:下载者在两次发送请求之间的时间间隔。Peers:一个字典的列表,每个字典包括以下关键字:Peer idIpPort,分别对应peer所选择的idip地址或者dns名称、端口号。注意,如果某些事件发生,或者需要更多的peers,那么下载者可能不定期的发送请求,

 

downloader 通过 HTTP GET 命令来向 tracker 发送查询请求,tracker 响应一个peers 的列表)

 

如果你想对元信息文件或者tracker查询进行扩展,那么需要同Bram Cohen协调,以确保所有的扩展都是兼容的。

 

BT对等协议基于TCP,它很有效率,并不需要设置任何socket选项。(译注:BT对等协议指的是peerpeer之间交换信息的协议)

对等的两个连接是对称的,消息在两个方向上同样的传递,数据也可以在任何一个方向上流动。

一旦某个peer下载完了一个片断,并且也检查了它的完整性,那么它就向它所有的peers宣布它拥有了这个片断。

 

 

连接的任何一端都包含两比特的状态信息:是否choked,是否感兴趣。Choking是通知对方,没有数据可以发送,除非unchoking发生。Choking的原因以及技术后文解释。

 

一旦一端状态变为interested,而另一端变为非choking,那么数据传输就开始了。(也就是说,一个peer,如果想从它的某个peer那里得到数据,那么,它首先必须将它两之间的连接设置为 interested,其实就是发一个消息过去,而另一个peer,要检查它是否应该给这个家伙发送数据,如果它对这个家伙是 unchoke,那么就可以给它发数据,否则还是不能给它数据)Interested状态必须一直被设置――任何时候。要用点技巧才能比较好的实现这个目的,但它使得下载者能够立刻知道哪些peers将开始下载。

 

对等协议由一个握手开始,后面是循环的消息流,每个消息的前面,都有一个数字来表示消息的长度。握手的过程首先是先发送19,然后发送“BitTorrent protocol”。19就是“BitTorrent protocol”的长度。

后续的所有的整数,都采用big-endian 来编码为4个字节

在协议名称之后,是8个保留的字节,这些字节当前都设置为0

接下来对元文件中的 info 信息,通过 sha1 计算后得到的 hash值,20个字节长。接收消息方,也会对 info 进行一个 hash 运算,如果这两个结果不一样,那么说明对方要的文件,并不是自己所要提供的,所以切断连接。

 

接下来是20个字节的 peer id

这就是握手过程

 

接下来就是以消息长度开始的消息流,这是可选的。长度为0 的消息,用于保持连接的活动状态,被忽略。通常每隔2分钟发送一个这样的消息。

 

其它类型的消息,都有一个字节长的消息类型,可能的值如下:

 

choke, unchoe, interested, not interested’类型的消息不再含有其它数据了。

 

bitfield’永远也仅仅是第一个被发送的消息。它的数据实际是一个位图,如果downloader已经发送了某个片断,那么对应的位置1,否则置0Downloaders如果一个片断也没有,可以忽略这个消息。(通过这个消息,能知道什么了?)

 

have’类型的消息,后面的数据是一个简单的数字,它是下载者刚刚下载完并检查过完整性的片断的索引。(由此,可以看到,peer通过这种消息,很快就相互了解了谁都有什么片断)

 

request’类型的消息,后面包含索引、开始位置和长度)长度是2的幂。当前的实现都用的是215 ,而关闭连接的时候,请求一个超过2 17的长度。(这种类型的消息,就是当一个peer希望另一个peer给它提供片断的时候,发出的请求)

 

cancel 类型的消息,它的数据和’request’消息一样。它们通常只在下载趋向完成的时候发送,也就是在‘结束模式“阶段发送。在一次下载接近完成的时候,最后的几个片断需要很长时间才能下载完。为了确保最后几个片断尽快下载完,它向所有的peers发送下载请求。为了保证这不带来可怕的低效,一旦某个片断下载完成,它就其它peers发送’cancel’消息。(意思就是说,我不要这个片断了,你要是准备好了,也不用给我发了,可以想象,如果对方还是把数据发送过来了,那么这边必须忽略这些重复的数据)。

 

 

piece’类型的消息,后面保护索引号、开始位置和实际的数据。注意,这种类型的消息和 request’消息之间有潜在的联系(译注:因为通常有了request消息之后,才会响应‘piece’消息)。如果chokeunchoke消息发送的过于迅速,或者,传输速度变的很慢,那么可能会读到一些并不是所期望的片断。( 也就是说,有时候读到了一些片断,但这些片断并不是所想要的)

谈论【测试】30秒测出你的年龄

 

引用

【测试】30秒测出你的年龄

一面读一面做:    
【1】首先,挑一个数字(0 -7)表示每个礼拜想出去走走的次数    

【2】把这个数字乘上2    

【3】然後加上5    

【4】再乘以50    

【5】如果你今年的生日已经过了,    
把得到的数目加上1756,    
如果还没过,加1755  

【6】最後一个步骤,用这个数目减去你出生的那一年    

【7】现在你会有一个三位数的数字    

【8】第一个位数是你一开始选择的数目(也就是每个星期你希望出去走走的次数)    

接下来的二个位数就是你的年龄

 

好准,

我的一岁都不差!

BitTorrent 协议规范(BT协议集合)一 A

 

BitTorrent 协议规范(BT协议集合)一


2005-11-21 1:09:27

翻译:小马哥

日期:2004-5-22

BitTorrent 是一种分发文件的协议。它通过URL来识别内容,并且可以无缝的和web进行交互。它基于HTTP协议,它的优势是:如果有多个下载者并发的下载同一个文件,那么,每个下载者也同时为其它下载者上传文件,这样,文件源可以支持大量的用户进行下载,而只带来适当的负载的增长。(译注:因为大量的负载被均衡到整个系统中,所以提供源文件的机器的负载只有少量增长)

 

一个BT文件分布系统由下列实体组成:

一个普通的web服务器

一个静态的“元信息”文件

一个跟踪(tracker)服务器

终端用户的web浏览器

终端下载者

 

理想的情况是多个终端用户在下载同一个文件。

要提供文件共享,那么一台主机需要执行以下步骤:

Ø运行一个 tracker服务器(或者,已经有一个tracker服务器在运行了也可以)

Ø运行一个web服务器,例如apache,或者已经有一个web服务器在运行了。

Øweb服务器上,将文件扩展名.torrent MIME类型 application/x-bittorrent关联起来(或者已经关联了)

Ø根据 tracker服务器的 URL 和要共享的文件来创建一个“元信息”文件(.torrent)。

Ø将“元信息”文件发布到web服务器上

Ø在某个web页面上,添加一个到“元信息”文件的链接。

Ø运行一个已经拥有完整文件的下载者(被成为’origin’,或者’seed’,种子)

 

要开始下载文件,那么终端用户执行以下步骤:

Ø安装 BT(或者已经安装)

Ø访问提供 .torrent 文件的web服务器

Ø点击到 .torrent 文件的链接(译注:这时候,bt会弹出一个对话框)

Ø选择要把下载的文件保存到哪里?或者是一次断点续传

Ø等待下载的完成。

Ø结束bt程序的运行(如果不主动结束,那么bt会一直为其它人提供文件上传)

 

各个部分之间的连通性如下:

网站负责提供一个静态的文件,而把BT辅助程序(客户端)放在客户端机器上。

Trackers从所有下载者处接收信息,并返回给它们一个随机的peers的列表。这种交互是通过HTTPHTTPS协议来完成的。

下载者周期性的向tracker登记,使得tracker能了解它们的进度;下载者之间通过直接连接进行数据的上传和下载。这种连接使用的是 BitTorrent 对等协议,它基于TCP

Origin只负责上传,从不下载,因为它已经拥有了完整的文件。Origin是必须的。

 

元文件和tracker的响应都采用的是一种简单、有效、可扩展的格式,被称为bencoding,它可以包含字符串和整数。由于对不需要的字典关键字可以忽略,所以这种格式具有可扩展性,其它选项以后可以方便的加进来。

Bencoding格式如下:

对于字符串,首先是一个字符串的长度,然后是冒号,后面跟着实际的字符串,例如:4:spam,就是“ spam

整数编码如下,以 i 开始,然后10进制的整数值,最后以’e’结尾。例如,i3e表示3I-3e表示-3。整数没有大小限制。I-0e是无效的。除了 i0e外,所以以0起始的整数都无效。I0e当然表示0

列表编码如下,以’l’开始,接下来是列表值的编码(也采用bencoded编码),最后以’e’结束。例如:l4:spam4:eggse 表示 [spam, eggs]

字典编码如下,以’d’开始,接下来是可选的keys和它对应的值,最户以’e’结束。例如:d3:cow3:moo4:spam4:eggse,表示 {cow:moo,spam:eggs},而d4:spaml1:al:bee 表示 {spam:[a,b]}。键值必须是字符串,而且已经排序(并非是按照字母顺序排序,而是根据原始的字符串进行排序)。

 

元文件是采用bencoded编码的字典,包括以下关键字:

 

announce tracker的服务器

 

info 它实际上是一个字典,包括以下关键字:

 

Name

一个字符串,在保存文件的时候,作为一个建议值。仅仅是个建议而已,你可以用别的名字保存文件。

Piece length

为了更好的传输,文件被分隔成等长的片断,除了最后一个片断以外,这个值就是片断的大小。片断大小几乎一直都是2的幂,最常用的是 256kBT的前一个版本3.2,用的是1M作为默认大小)

Pieces

一个长度为20的整数倍的字符串。它将再被分隔为20字节长的字符串,每个子串都是相应片断的hash值。

 

此外,还有一个lengthfiles的关键字,这两个关键字只能出现一个。如果是length,那么表示要下载的仅仅是单个文件,如果是files那么要下载的是一个目录中的多个文件。

如果是单个文件,那么length是该文件的长度。

 

为了能支持其它关键字,对于多个文件的情况,也把它当作一个文件来看,也就是按照文件出现的顺序,把每个文件的信息连接起来,形成一个字符串。每个文件的信息实际上也是一个字典,包括以下关键字:

Length:文件长度

Path:子目录名称的列表,列表最后一项是文件的实际名称。(不允许出现列表为空的情况)。

Name:在单文件情况下,name是文件的名称,而在多文件情况下,name是目录的名称。

 BitTorrent 协议规范(BT协议集合)一 B

MTU[最大传输单位]

MTU[最大传输单位]

Submitted by 剑气凌人 on 2005-4-16 16:8:5 | 字号:
今天搞一个网络,死活出问题,后来才发觉是MTU值设定的错误,自己总结了一下

当电脑连接网络传送资料时,资料会分割为不同大小的封包, MTU值设定。MTU是英文Maximum Transmission Unit的缩写,意为“最大传输单位”。也就是通过TCP/IP协议所传输的数据包最大有多少字节, MTU值越大,封包就越大,理论上可增加传送速率,但MTU值又不能设得太大,因为封包太大,传送时出现错误的机会大增。一般默认的设置,PPPoE连接的最高MTU值是1492, 而以太网(Ethernet)的最高MTU值则是1500,而在Internet上,默认的MTU大小是576字节, 为什么会有这种差别呢?一般而言,LAN就不说了吧,为充分发挥LAN的效能,MTU可以稍微大一点。Internet的情况恰好相反,对拨号用户来说, 那叫一个慢呀。因此,对于Internet,应当采用较小的数据包。 MTU值设定与宽带接入方式的不同也会影响上网速度,通常推荐的MTU配置是:对于拨号用户,设置成576;对于使用PPPoE的DSL用户,设置成 1400;对于其他用户,设置成1500。

ping http://www.blueidea.com -f -l 1480

出现 Packet needs to be fragmented but DF set.就说明该大小的(1480字节)数据包超过了ISP的MaxMTU,产生了数据冲突碎片,那么我们就降低Ping命令中的数据包大小,比如说是 1460一直到返回信息是Reply from 220.194.57.26: bytes=1460 time=134ms TTL=115才算正常,那个这个1460数据包大小的值就是ISP的PPPoE协议的MaxMTU值

9X系统中如下设定,运行 ==regedit回车,进入注册表。依次展开HKEY_LOCAT_MACHINE\System\CurrentControlSet\ Services\Class\NetTrans\,会看到包含几个000X的子项,寻找含有键名为“DriverDesc”,键值为“TCP/IP”的 000X主键,该键里有该计算机的网络属性设置,如IP地址192.168.0.XX,网关 192.168.0.1,子网掩码255.255.255.0等。在该键下新建“DWORD值”,命名为“MaxMtu”,修改键值为十进制的1460,

Win95,98系统:
打开注册表编辑器,找到位置 “HKEY_LOCAT_MACHINE\System\CurrentControlSet\Services\Class\NetTrans00x”, “x”表示为数字,假如电脑安装了多个通讯协议,就会出现“0001”、“0002”、“0003”等项目,只要打开该项目,就会看见 “DriverDesc”是“TCP/IP”,即网卡的“Registry”设置,用户在这里可按鼠标右键新增一个“MaxMTU”的DWORD值,修改键值为十进制的1460,重启。

Win2000,NT,XP,2003系统可以采用如下2种方法之一,建议采用第一种,如果不行,依次往下试验
1,启用PMTUD的backhole传输

打开REGEDIT,HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters\主键下,找到主键 EnablePMTUBHDetect ,如果没有则创建这个Dword值,将其键值设置为1,保存后重起计算机,并测试故障是否解决?
2, 手工设置网卡的MTU值

打开REGEDIT,HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters\Interfaces\主键下,下面会有几个文件夹,分别代表机器的安装的每一块网卡,依次浏览每个文件夹,并察看窗口右边 IPAddress的键值,如果其值为你连接 Internet所用网卡的ip,则需要修改的就是这个文件夹。
进入此文件夹,找到一个名为MTU的主键,如果没有则创建这个Dword值,修改键值为十进制的1460,重启。