RFC-1036:[Previous][Up to Table of Contents] [Next]
RFC1036 3.2. Ihave/Sendme

ihave <Message-ID list> [<remotesys>]

sendme <Message-ID list> [<remotesys>]

This message is part of the ihave/sendme protocol, which allows one host (say A) to tell another host (B) that a particular message has been received on A. Suppose that host A receives message "<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message to host B.

A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A" to host B (by posting it to newsgroup to.B). B responds with the control message "sendme <1234@ucbvax.Berkeley.edu> B" (on newsgroup to.A), if it has not already received the message. Upon receiving the sendme message, A sends the message to B.

This protocol can be used to cut down on redundant traffic between hosts. It is optional and should be used only if the particular situation makes it worthwhile. Frequently, the outcome is that, since most original messages are short, and since there is a high overhead to start sending a new message with UUCP, it costs as much to send the ihave as it would cost to send the message itself.

One possible solution to this overhead problem is to batch requests. Several Message-ID's may be announced or requested in one message. If no Message-ID's are listed in the control message, the body of the message should be scanned for Message-ID's, one per line.

RFC1036: [Source:"RFC-1036"] [Last Changed:December 1987] [Copyright: 1987 M. Horton, R. Adams]
RFC-1036:[Previous][Up to Table of Contents] [Next]



(Corrections, notes, and links for Usenet RKT.)
by Mib Software, INN customization and consulting

-B-r-o-a-d-e-n- your knowledge

Up to RFC1036 3. Control Messages

Examine in depth

Optional Header Lines: RFC1036 2.2.6. Control


RKT Rapid-Links:[Search] [RKT Tips] Path:For Developers / NNTProtocol / RFC1036 / Control Messages / 0063.htm