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

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’呢?
 
 
Advertisements

关于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消息发送的过于迅速,或者,传输速度变的很慢,那么可能会读到一些并不是所期望的片断。( 也就是说,有时候读到了一些片断,但这些片断并不是所想要的)