La réponse à cette question est OUI! Le Usenet a un original « standard » qui peut être vu ci-dessous.

Kantor Network Groupe de travail Brian (UC San Diego)
Request for Comments: 977 Lapsley Phil (UC Berkeley)
Février 1986

Nouvelles du Réseau de transfert
Protocole

Une proposition de norme pour la
Stream-Based
Transmission des Nouvelles

Statut de ce mémo

NNTP spécifie un protocole pour la distribution, enquête, recherche,
et l’affichage des articles de nouvelles en utilisant un
fiable basée sur les flux
transmission de nouvelles dans la communauté ARPA-Internet. NNTP est
conçu de façon que les articles de nouvelles sont stockées dans une base de données centrale
permettant à un abonné de choisir uniquement les éléments qu’il souhaite lire.
D’indexation, des renvois, et l’expiration des messages âgés sont également
fourni. Ce RFC suggère un protocole proposé pour la
ARPA-Internet
communauté, et des discussions et suggestions d’améliorations.
La distribution de ce mémo est illimitée

1. Introduction

Pendant de nombreuses années, la communauté ARPA-Internet a soutenu la
distribution des bulletins, des informations et des données dans un
temps opportun
à des milliers de participants. Nous collectivement référence à ces éléments de
informations comme des «nouvelles». Ces nouvelles prévoit la
rapide
diffusion d’objets d’intérêt tels que des corrections de bugs logiciels,
nouvelles
revues de produits, conseils techniques, et des pointeurs de programmation, ainsi que
discussions à tir rapide de questions d’intérêt pour le travail
ordinateur
professionnel. Nouvelles est très populaire parmi ses lecteurs.

Il ya généralement deux méthodes de distribution de ces nouvelles: l’
Méthode Internet de mailing direct, et le système de nouvelles Usenet

1.1. Listes de diffusion Internet

La communauté Internet distribue des nouvelles par l’utilisation de listes de diffusion.
Ce sont des listes d’adresses de boîtes aux lettres de l’abonné et
repostage
sous-listes de tous les destinataires prévus. Ces listes de diffusion fonctionnent par
repostage une copie de l’information à être distribué à chaque
abonné à la liste de diffusion. Repostage est inefficace quand un
liste de diffusion croît au-delà d’une dizaine de personnes, depuis l’envoi d’un
copie distincte à chacun des abonnés occupe de grandes quantités de
bande passante du réseau, les ressources du processeur, et d’importantes quantités de
disque
stockage à l’hôte de destination. Il ya aussi un problème important
dans le maintien de la liste elle-même: à mesure que les abonnés d’un
emploi
à l’autre, comme les nouveaux abonnés se joindre et quitter les anciens, et comme
hôtes
entrer et sortir de service.
.

Kantor et Lapsley [Page 1]

.

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole.

1.2. Le système de Nouvelles USENET

De toute évidence, une réduction de peine du montant de ces ressources utilisées
peut être obtenue si les articles sont stockés dans une base de données centrale sur les
réception d’accueil au lieu de la boîte aux lettres de chaque abonné. Le
USENET
système de nouvelles fournit une méthode de faire justement cela. Il ya une
centrale
dépôt des statuts nouvelles en un seul endroit (habituellement un
bobine
répertoire de quelque sorte), et un ensemble de programmes qui permettent à un
abonné de sélectionner les éléments qu’il souhaite lire. D’indexation,
les références croisées, et d’expiration des messages âgés sont également fournis

1.3. Storage Central des Nouvelles

Pour les clusters de serveurs reliés entre eux par des réseaux locaux rapides
(comme Ethernet), il est encore plus logique de regrouper
nouvelles
distribution sur un (ou très peu) les hôtes, et de permettre l’accès à
ces articles de nouvelles en utilisant un serveur et le modèle client. Les abonnés peuvent
puis demande que les articles qu’ils souhaitent voir, sans avoir à
inutilement double emploi avec le stockage d’une copie de chaque élément sur ​​chaque hôte.

1.4. Un serveur central Nouvelles

Une façon de réaliser ces économies est d’avoir un ordinateur central
système
qui peuvent fournir des service de nouvelles aux autres systèmes sur le
zone locale
réseau. Un tel serveur serait de gérer la collecte des articles de nouvelles
fichiers d’index et, avec chaque personne qui veut lire des bulletins de nouvelles
faire sur le réseau local. Pour un grand groupe de systèmes informatiques, la
l’épargne dans l’espace disque total est clairement utile. En outre, cela permet
postes de travail avec un espace disque de stockage limitée à participer à la
nouvelles sans les éléments entrants consommant des quantités d’oppression de la
stockage sur disque poste de travail..

Nous avons entendu des rumeurs de tentatives de fournir un certain succès
service de nouvelles centralisée au moyen d’IBIS et d’autres
partagés ou répartis
les systèmes de fichiers. Bien qu’il soit possible qu’une telle distribués
fichier
mise en œuvre du système pourrait bien fonctionner avec un groupe de
similaires
ordinateurs exécutant les systèmes d’exploitation presque identiques, un tel régime
n’est pas suffisamment général pour offrir des services à un large éventail de
client
systèmes, en particulier lorsque de nombreux systèmes d’exploitation différents peuvent être en cours d’utilisation
parmi un groupe de clients. Il ya peu (le cas échéant)
partagé ou en réseau
les systèmes de fichiers qui peuvent offrir la généralité de ce service qui
flux
connexions utilisant Internet TCP fournir, en particulier quand un
large
gamme de matériel de l’hôte et les systèmes d’exploitation sont considérés comme..

NNTP spécifie un protocole pour la distribution, enquête, recherche,
et l’affichage des articles de nouvelles en utilisant une source fiable (comme TCP)
modèle client-serveur. NNTP est conçu de sorte que les articles nouvelles suffit

Kantor & Lapsley [Page 2]

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

être stockées sur une (probablement central) d’accueil, et les abonnés sur
autres
hôtes connectés au réseau local peut lire des articles de nouvelles utilisant
flux
connexions à l’hôte nouvelles.

NNTP est calquée sur l’article de nouvelles spécifications dans la RFC 850,
qui décrit le système de nouvelles Usenet. Toutefois, NNTP permet
quelques
exigences sur la structure, le contenu ou le stockage d’articles de nouvelles, et
Ainsi, nous croyons qu’il peut facilement être adapté à d’autres
nouvelles non-USENET
systèmes.

Typiquement, le serveur NNTP s’exécute comme un processus d’arrière-plan sur un hôte,
et accepte les connexions à partir d’autres hôtes sur le LAN. Cela fonctionne
bien quand il ya un certain nombre de petits systèmes informatiques (tels que
postes de travail, avec un seul ou tout au plus quelques utilisateurs chacun), et une grande
serveur central

1.5. Serveurs Nouvelles intermédiaire

Pour les clusters de machines avec de nombreux utilisateurs (comme cela peut être le cas dans un
université ou grande environnement industriel), un serveur intermédiaire
pourraient être utilisés. Cet intermédiaire ou ‘esclave ‘ serveur s’exécute sur chaque
système informatique, et est responsable de la médiation de nouvelles lecture
demandes et d’interprétation de la mise en cache locale
nouvelles récemment récupéré
articles

Typiquement, un client qui tente d’obtenir d’abord service de nouvelles
essayez de vous connecter au port service de nouvelles sur la machine locale. Si
cette tentative a été infructueuse, indiquant un serveur en panne, un
installation peut choisir soit de refuser l’accès des nouvelles, ou pour permettre
connexion au serveur central de nouvelles «maître».

Pour postes de travail ou d’autres petits systèmes, connexion directe à la
serveur maître serait probablement la manière normale de fonctionnement

Cette spécification ne couvre pas le fonctionnement de
esclave NNTP
serveurs. Nous nous contentons de suggérer que les serveurs esclaves constituent un complément logique
à l’utilisation du serveur NNTP qui améliorent le fonctionnement sur ​​de grandes
locales
réseaux

1.6. Distribution Nouvelles

NNTP a des commandes qui fournissent une méthode simple de
articles échange entre les hôtes ayant coopéré. Les hôtes qui sont bien
connecté sur un réseau local ou autre rapide et qui souhaitent
effectivement obtenir des copies des articles de nouvelles pour le stockage local pourrait bien
NNTP trouver un moyen plus efficace de distribuer de nouvelles que
plus
méthodes de transfert traditionnelles (comme UUCP).
.

Kantor & Lapsley [Page 3]

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

Dans la méthode traditionnelle de distribution articles de nouvelles, les nouvelles sont
propagée d’un hôte à des inondations – qui est, chaque hôte
envoyer tous les articles de nouvelles nouvelles sur chaque hôte qui l’alimente. Ces
accueille alors à son tour envoyer ces nouveaux articles sur d’autres hôtes
qu’ils se nourrissent. De toute évidence, l’envoi d’articles que l’hôte a déjà
a obtenu une copie d’un autre de l’alimentation (de nombreux hôtes qui reçoivent
nouvelles
sont nourris de manière redondante) est de nouveau une perte de temps et
communications
ressources, mais des mécanismes de transport qui sont
single-transaction
plutôt que interactifs (comme UUCP dans le monde UNIX <1>),
temps de distribution est diminuée par l’envoi de tous articles et ayant
l’hôte récepteur simplement jeter les doublons. Il s’agit d’un
particulièrement vrai lorsque des sessions de communication sont limités à une fois par
jour.

En utilisant NNTP, hôtes articles échanger des nouvelles ont un
interactive
mécanisme permettant de déterminer quels articles doivent être transmises. Un
accueil
Désireux de nouvelles nouvelles, ou qui a des nouvelles d’envoyer de nouvelles, sera généralement
contact avec une ou plusieurs de ses voisins avec le protocole NNTP. D’abord, il sera
demander si les groupes de nouvelles ont été créés sur le
service d’accueil
au moyen de la commande NEWGROUPS. Si c’est le cas, et ceux qui sont appropriées
ou souhaité (tel qu’établi par des règles locales site-dépendant), ces nouveaux
groupes de discussion peuvent être créés..

il sera ensuite l’hôte client se renseigner au sujet de nouveaux articles ont
est arrivé à tout ou partie des groupes de discussion qu’il désire recevoir,
en utilisant la commande NewNews. Il recevra une liste des nouveaux articles
à partir du serveur, et peut demander la transmission de ces articles que
elle le désire et ne possède pas déjà

Enfin, le client peut informer le serveur de ces nouveaux articles
le client a reçu récemment. Le serveur va indiquer les
articles qu’il a déjà obtenu des copies, et dont les statuts
doivent être envoyées à ajouter à sa collection.

De cette manière, seuls les articles qui ne sont pas des doublons et
qui sont souhaitées sont transférés

Kantor & Lapsley [Page 4]

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

2. La spécification NNTP

2.1. Vue d’ensemble

Le serveur de nouvelles définies par le présent document utilise un flux de connexion
(comme TCP) et les commandes SMTP-like et les réponses. Il est conçu
pour accepter les connexions à partir d’hôtes, et de fournir une interface simple
à la base de données nouvelles

Ce serveur n’est qu’une interface entre les programmes et les nouvelles
bases de données. Il n’effectue aucune interaction avec l’utilisateur ou
-présentation
fonctions de niveau. Ces ‘user-friendly’ fonctions vaut mieux laisser aux
les programmes clients, qui ont une meilleure compréhension de la
environnement dans lequel ils opèrent.

Lorsqu’il est utilisé via Internet TCP, le port de contact attribuée à cette
service est de 119.

2.2. Codes de caractères

Les commandes et réponses sont composés de caractères de l’ASCII
jeu de caractères. Lorsque le service de transport fournit un
8-bit octet
(octet) canal de transmission, chaque caractère 7-bit est transmis
justifiées à droite dans un octet avec le bit de haute remis à zéro

2.3. Commandes

Les commandes sont constituées d’un mot de commande, qui dans certains cas peut être
suivi d’un paramètre. Les commandes avec paramètres doivent séparer les
paramètres les uns des autres et de la commande par un ou plusieurs
espace
ou de tabulations. Les lignes de commande doit être accompagnée de toutes
nécessaire
paramètres, et ne peut contenir plus d’une commande.

Les paramètres des commandes et des commandes ne sont pas sensibles à la casse. C’est, un
commande ou un mot paramètre peut être en majuscules, minuscules, ou tout
mélange de majuscules et minuscules

Chaque ligne de commande doit être terminée par un CR-LF (Carriage Return –
Line Feed) paire.

Les lignes de commande ne doit pas dépasser 512 caractères, en comptant tous
caractères, espaces compris, séparateurs, la ponctuation, et la
CR-LF (il ya donc un maximum de 510 caractères autorisés pour la
et ses paramètres). Il n’existe aucune disposition pour la poursuite
lignes de commande.

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

2.4. Réponses

Les réponses sont de deux sortes, des textes et le statut.

2.4.1. Réponses textuelles

Le texte est envoyé seulement après une ligne d’état numérique réponse a été envoyée
qui indique que le texte suivra. Le texte est envoyé en une série de
lignes successives de la matière textuelle, chacune terminée par paire CR-LF.
Une seule ligne contenant seulement un point (.) est envoyé pour indiquer la
fin du texte (à savoir, le serveur envoie une paire CR-LF à la fin
de la dernière ligne du texte, une période, et une autre paire CR-LF)

Si le texte prévoyait un délai que le premier caractère de la
texte
ligne dans l’original, cette première période est doublée. Par conséquent, la
client doit examiner le premier caractère de chaque ligne reçue, et
pour ceux qui commencent par une période, soit de déterminer qu’il s’agit de la
fin du texte ou si pour réduire la période doublé pour atteindre un seul
une.

L’intention est que les messages texte sera généralement affiché sur la
terminal de l’utilisateur alors que les réponses commande d’état / sera interprété
par le programme client avant tout affichage est possible soit fait

2.4.2. Les réponses d’état

Ce sont des rapports d’état du serveur et d’indiquer la réponse à
la dernière commande reçue du client

Lignes de réponse statut commencer par un code à 3 chiffres numériques qui est
suffisante pour distinguer toutes les réponses. Certains d’entre eux peuvent annoncer
la transmission ultérieure du texte..

Le premier chiffre de la réponse indique généralement le succès,
échec, ou la progression de la commande précédente.

1xx – Informatif
message
2xx – Commandement ok
3xx – Commandement ok à ce jour, envoyer le reste
.
4xx – Command a été correct, mais n’a pas pu être effectuée pour
une raison quelconque.
5xx – Commande non implémentée, ou incorrecte, ou un
graves
erreur de programme a eu lieu.

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

Le chiffre suivant dans le code indique la catégorie de réponse de la fonction.

x0x – connexion, la configuration et messages divers
x1x –
Newsgroup sélection
x2x –
Article sélection
x3x – Les fonctions de distribution
x4x – Détachement
x8x – non standard (la mise en œuvre privée) extensions
X9X – sortie de débogage

Les codes de réponse exacte que devrait être attendu de chaque
commande
sont détaillées dans la description de cette commande. En outre,
ci-dessous
est répertorié un ensemble général de codes de réponse qui peuvent être reçus à n’importe quel
temps

Les réponses d’état Certaines contiennent des paramètres tels que les numéros et
noms. Le nombre et le type de paramètres est fixé pour chaque
code de réponse pour simplifier l’interprétation de la réponse.

Les paramètres sont séparés du code de réponse numérique et de chaque
d’autres par un espace. Tous les paramètres numériques sont décimales, et peut
ont des zéros. Tous les paramètres de chaîne commençant après la séparation
l’espace, et à la fin avant que l’espace qui suit la séparation ou le
CR-LF
paire à la fin de la ligne. (Les paramètres de chaîne ne peut donc pas
,
contenir des espaces.) Tout le texte, le cas échéant, dans la réponse qui n’est pas un
paramètre de la réponse doit suivre et d’être séparée de la dernière
paramètre par un espace. En outre, notez que le texte suivant un
réponse
nombre peut varier dans les différentes implémentations du serveur. Le
Code à 3 chiffres numériques devraient être utilisés pour déterminer quelle réponse a été
envoyé.

Les codes de réponse non indiquées dans cette norme peut être utilisée pour toute
spécifique à l’installation des commandes supplémentaires également pas spécifié. Ces
devraient être choisis en fonction de la configuration des x8x spécifié ci-dessus. (Note
que le débogage est prévu explicitement dans les codes de réponse X9X.)
L’utilisation de codes de réponse non précisée pour les commandes standard est
interdite.

Nous avons fourni un modèle de réponse X9X pour le débogage. Depuis
beaucoup
la sortie de débogage peuvent être classés comme ‘des messages d’information», nous
donc s’attendre à ce que les réponses 190 à 199 seraient utilisés pour
différentes sorties de débogage. Il n’est pas nécessaire dans ce
cahier des charges de la sortie de débogage, mais si tel est prévue au cours de la
flux connecté, il faut utiliser ces codes de réponse. Si
appropriées
à une mise en œuvre spécifiques, codes X9X d’autres peuvent être utilisés pour
débogage. (Un exemple pourrait être d’utiliser par exemple, 290 à accuser un
demande à distance le débogage.)

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

2.4.3. Réponses générales

Ce qui suit est une liste de codes de réponse générale qui peuvent être envoyés par
le serveur NNTP. Ce ne sont pas spécifiques à une commande un, mais peut
être retourné à la suite d’une connexion, un échec, ou quelque
inhabituelle
condition..

En général, les codes 1xx peuvent être ignorées ou affichées à volonté;
code
200 ou 201 est envoyé lors de la connexion initiale à la
serveur NNTP
en fonction de l’affichage permission; le code 400 sera envoyé lorsque l’
Serveur NNTP cesse de service (par demander à l’exploitant, par exemple);
et les codes 5xx indiquer que la commande ne peut être réalisée pour
une raison exceptionnelle..

100 suit le texte d’aide
199 sortie de débogage

200 serveur prêt – Affichage interdit
201 serveur prêt – Affichage interdit

400 service interrompu

500 commande non reconnue
501 commande
erreur de syntaxe
502 de restriction d’accès ou permission refusée
503 erreur de programme – commande pas effectué

3. Détails de commandement et d’intervention

Sur les pages suivantes sont des descriptions de chaque commande reconnue par
le serveur NNTP et les réponses qui seront retournés par ces
commandes.

Chaque commande est indiqué en majuscules pour plus de clarté, même si le cas est
ignorées dans l’interprétation des commandes par le serveur NNTP. Tout
les paramètres sont affichés en minuscules. Un paramètre montré dans [
carrés
crochets] est facultatif. Par exemple, [GMT] indique que la
GMT triglyphe peut présenter ou omis.

Chaque commande décrites dans cette section doit être mis en œuvre par tous les
Serveurs NNTP.
.

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

Il n’y a aucune interdiction de commandes supplémentaires seront ajoutés;
Toutefois, il est recommandé que toute commande telle indéterminée commencer
avec la lettre ‘X’ pour éviter tout conflit avec les révisions ultérieures de ce
cahier des charges

Mise en œuvre Il est rappelé que ces commandes supplémentaires ne peuvent pas
redéfinir les codes de réponse spécifié statut. Utilisation
supplémentaires
réponses non précisée pour les commandes standard est également interdit..

3.1. L’ARTICLE, corps, la tête, et les commandes STAT.

Il existe deux formes de la commande article (et l’organisme apparenté,
HEAD, et les commandes STAT), chacun utilisant une méthode différente de préciser
dont l’article doit être récupéré. Lorsque la commande est ARTICLE
suivi par un message-id entre crochets (‘<‘et ‘>’), l’
premier
forme de la commande est utilisée, quand un paramètre numérique ou pas
paramètre
est fourni, la deuxième forme est appelée..

Le texte de l’article est retourné comme une réponse textuelle, comme
décrite précédemment dans ce document..

La HEAD et BODY commandes sont identiques à la
ARTICLE commande
sauf qu’ils ont respectivement retourner uniquement les lignes d’en-tête ou
texte
corps de l’article..

La commande STAT est similaire à la commande article, sauf que pas
texte est renvoyé. Lors de la sélection par numéro de message dans un groupe,
la commande STAT permet de régler le pointeur de l’actuel article sans
l’envoi des SMS. La réponse d’accusés de réception contiendra le
Message-ID, qui peut être d’une certaine valeur. Utilisation de la commande STAT pour
Sélectionnez par message-id est valide, mais d’une utilité douteuse, car un
sélection par message-id ne modifie pas le ‘pointeur actuel article’.

3.1.1. ARTICLE (sélection par message-id)

ARTICLE

Afficher l’en-tête, une ligne vide, puis le corps (texte) de la
spécifiée article. Message-id est l’identifiant de message d’un article que
représenté sur la tête que l’article. Il est prévu que le client
obtiendrez le message-id d’une liste fournie par le
NewNews
commande, à partir des références contenues dans un autre article, ou de
le message-id fournis dans la réponse à d’autres commandes..

S’il vous plaît noter que l’intérieur entretenu ‘actuelle du pointeur article’
n’est pas modifié par cette commande. C’est à la fois de faciliter la
présentation des articles susceptibles d’être référencés au sein d’un
article

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

en cours de lecture, et en raison des difficultés sémantiques de la détermination de
le bon ordre et la composition d’un article qui peut avoir été
posté à plus d’un groupe de discussion

3.1.2. ARTICLE (sélection par numéro)

ARTICLE [nnn]

Affiche l’en-tête, une ligne vide, puis le corps (texte) de la
article courant ou spécifié. Le nnn paramètre optionnel est le

Identifiant numérique d’un article dans le groupe de discussion en cours et doit être choisi
de la gamme des articles fournis lorsque le groupe de discussion a été sélectionné.
Si elle est omise, l’article actuel est supposé.

L’intérieur entretenu ‘pointeur actuel article’ est défini par le présent
commande

[ce qui suit s’applique aux deux formes de la commande article.] Un
réponse indiquant que le numéro de l’article actuel, une chaîne de message-id,
et que le texte est à suivre vous sera retourné..

La chaîne de message-id retourné est une chaîne d’identification figurant
dans les crochets (‘<‘et ‘>’), qui est dérivé de l’en-tête
de l’article lui-même. La ligne d’en-tête Message-ID (requis par
RFC850) de l’article doit être utilisé pour fournir ces informations. Si
la ligne d’en-tête Message-ID est absent de l’article, un seul
chiffre ‘0’ (zéro) doit être fournie dans les équerres.

Depuis le champ du message-id est unique à chaque article, il peut être
écrans utilisés par un programme de lecture nouvelles de sauter en double des articles
qui ont été écrit plus d’une fois, ou à plus d’un groupe de discussion.

3.1.3. Réponses

Article 220 n récupérés – tête et le corps suivent
(numéro de l’article n =, = Message-ID)
221 n article trouvé – tête suit
222 n article trouvé – corps suit
223 Article n récupérés –
texte de la demande séparément
412 pas de groupe de discussion a été sélectionné
420 pas de l’actuel article a été sélectionné
423 pas de numéro de tel article dans ce groupe
430 pas de tel article trouvé

 

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

 

3.2. La commande GROUP

3.2.1. GROUPE

GROUPE ggg

Til avait besoin ggg paramètre est le nom du groupe de discussion à
sélectionnée (par exemple « net.news »). Une liste des groupes de discussion peut être valablement
obtenu à partir de la commande LIST.

La réponse à la sélection réussit, vous recevrez les numéros article de
les articles premier et le dernier dans le groupe, et une estimation de la
certain nombre d’articles sur le fichier dans le groupe. Il n’est pas nécessaire que
l’estimation est correcte, bien que cela soit utile, il ne doit être
égal ou plus grand que le nombre réel d’articles sur le fichier. (Certains
implémentations en comptant le nombre d’articles sur le fichier.
D’autres vont juste soustraire numéro de l’article premier de la dernière à obtenir un
estimation.)

Quand un groupe valide est sélectionné au moyen de cette commande, la
interne maintenu ‘pointeur actuel article’est réglé sur la première
article dans le groupe. Si un groupe non valide est spécifiée, l’
sélectionnés groupe et de l’article restent sélectionnés. Si un
vide
groupe de discussion est sélectionné, le pointeur actuel article ‘est dans un
état indéterminé et ne doit pas être utilisé

où est le nom du groupe de discussion, est le nombre de
le dernier article connus actuellement dans ce groupe de discussion, est la
numéro de l’article premier moment dans le forum, et

soit ‘y’ ou ‘n’ indiquant si la publication dans ce groupe de discussion est
autorisés («y») ou interdit (‘n’).

3.2.2. Réponses

211 n f l s
groupe sélectionné
(n = nombre estimatif d’articles dans le groupe,
f =
numéro de l’article premier dans le groupe,
l = dernier numéro d’article dans le groupe,
s = nom du groupe.)
411 pas de groupe telles nouvelles

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

3.3. La commande HELP

3.3.1. HELP

HELP

Fournit un bref résumé des commandes comprises par ce
mise en œuvre du serveur. Le texte d’aide sera présenté comme un
réponse textuelle, terminé par une seule période sur une ligne par lui-même.

3.3.2. Réponses

100 suit le texte d’aide
199 sortie de débogage

3.4. La commande IHAVE

3.4.1. IHAVE

IHAVE

La commande IHAVE informe le serveur que le client dispose d’un
article
dont l’id est . Si le serveur désire une copie de cette
article, il sera de retour une réponse demandant au client d’envoyer le
article dans son intégralité. Si le serveur ne veut pas l’article (si, par
Par exemple, le serveur a déjà une copie de celui-ci), une réponse indiquant
que l’article n’est pas voulu vous sera retourné

Si la transmission de cet article est demandé, le client doit envoyer
l’article en entier, y compris en-tête et le corps, dans le
manière
spécifié pour la transmission du texte à partir du serveur. Un code de réponse
indiquant le succès ou l’échec du transfert de l’article sera
être retournés

Cette fonction diffère de la commande POST en ce qu’il est destiné
pour le transfert de déjà-publié des articles entre les hôtes.
Normalement, il ne sera pas utilisée lorsque le client est un
personnels
newsreading programme. En particulier, cette fonction appelle la
émission de nouvelles annonce du serveur avec les paramètres appropriés (drapeaux,
options, etc) pour indiquer que le prochain article est
transmis par un autre hôte.

Le serveur peut, cependant, choisir de ne pas afficher ou envoyer l’article si
après un examen plus approfondi de l’article, il estime qu’il est inapproprié de
le faire. Les codes d’erreur 436 ou 437 peut être retourné, le cas échéant à
la situation.

Motifs de rejet ultérieur d’un tel article peut comprendre
tels

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

problèmes que les groupes de discussion inappropriée ou distributions,
espace disque
limitations, les longueurs de l’article, en-têtes tronquées, etc. Ces
sont généralement des restrictions appliquées par

logiciels et pas nécessairement le serveur NNTP lui-même

3.4.2. Réponses

235 article cédé ok
335 article envoyer à être transféré. Fin avec .
435 article ne voulait pas – ne pas envoyer
436 Echec du transfert – essayez plus tard
437 article rejeté – ne pas essayer de nouveau

Une note mise en œuvre:

Parce que certains logiciels nouvelles hôte détachement ne peut pas être en mesure de décider
immédiatement qu’un article n’est pas approprié pour l’affichage ou
expédition, il est acceptable d’accuser
transfert réussi
de l’article et pour plus tard, en silence le jeter. Ainsi, il est
autorisé à retourner le code 235 et, plus tard accusé jeter
l’article reçu. Ce n’est pas une solution pleinement satisfaisante à
le problème. Peut-être que certaines implémentations voudront envoyer un mail à
l’auteur de l’article dans certains de ces cas.

3.5. La dernière commande

3.5.1. DERNIER

DERNIER

L’intérieur maintenu ‘pointeur actuel article’est réglé sur la
article précédent dans le groupe de discussion en cours. Si vous êtes déjà positionné à
le premier article du groupe de discussion, un message d’erreur est retourné et
l’article actuel reste sélectionné

L’intérieur entretenu ‘pointeur actuel article’ est défini par le présent
commande

Une réponse indiquant le numéro de l’article actuel, et un
message-id
string sera retournée. Aucun texte est envoyé en réponse à cette
commande

3.5.2. Réponses

223 article na trouvé –
texte de la demande séparément
(numéro de l’article n =, un article unique id =)
412 pas de groupe de discussion sélectionné
420 pas de l’actuel article a été sélectionné
421 pas d’article suivant dans ce groupe

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

412 pas de groupe de discussion sélectionné
420 pas de l’actuel article a été sélectionné
422 sans précédent article de ce groupe

3.6. La commande LIST

3.6.1. LISTE

LISTE

Retourne une liste de groupes de discussion valable et les informations associées. Chaque
newsgroup est envoyé comme une ligne de texte dans le format suivant:

dernier groupe p premiers

où est le nom du groupe de discussion, est le nombre de
le dernier article connus actuellement dans ce groupe de discussion, est la
numéro de l’article premier moment dans le forum, et

soit ‘y’ ou ‘n’ indiquant si la publication dans ce groupe de discussion est
autorisés («y») ou interdit (‘n’)..

Le et les champs sera toujours numérique. Ils peuvent avoir
zéros. Si le champ évalue à moins de la
domaine , il n’y a pas d’articles actuellement dans les dossiers du
groupe de discussion..

Notez que l’affichage peut encore être interdite à un client, même si le
Commande LIST indique que l’affichage est permis à un particulier
groupe de discussion. Voir le poste de commandement pour une explication de
client
interdictions. Le drapeau affichage existe pour chaque groupe de discussion, car
certains groupes de discussion sont modérés ou sont condensés, et ne peuvent donc pas être
affecté à, c’est-articles postés entre eux doit être envoyée à un
modérateur qui leur poste pour le demandeur. C’est
indépendants
de l’autorisation accordée annonce à un client par le serveur NNTP.

S’il vous plaît noter que la liste vide (ie, le corps du texte retourné par cette
commande est composée uniquement de la période de fin) est un
possible valide
réponse, et indique qu’il ya actuellement pas de groupes de discussion valable

3.6.2. Réponses

215 liste des groupes de discussion suit

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

3.7. La commande NEWGROUPS

3.7.1. NEWGROUPS

NEWGROUPS date et l’heure [GMT] []

Une liste des groupes de discussion créés depuis seront répertoriés dans
le même format que la commande LIST

La date d’envoi de 6 chiffres dans le format, AAMMJJ où YY est la
les deux derniers chiffres de l’année, MM les deux chiffres du mois (avec
des zéros, le cas échéant), et JJ le jour du mois (avec
des zéros, le cas échéant). Le plus proche siècle est supposé que
partie de l’année (soit 86 spécifie 1986, 30 spécifie 2030, 99 est
1999, 00 est 2000)..

Le temps doit être également précisé. Il doit être composé de 6 chiffres HHMMSS
avec HH
étant heures sur l’horloge de 24 heures, les minutes MM 00-59, et les secondes SS
00-59. Le temps est supposé être dans le fuseau horaire du serveur à moins que le
jeton ‘GMT’ apparaît, dans ce cas, deux heure et la date sont évalués
au méridien 0.

Le paramètre optionnel ‘distributions’ est une liste de distribution
groupes, entourées de crochets pointus. Si spécifié, la distribution
partie d’un groupe de discussion de nouvelles (par exemple, «net» dans «net.wombat») sera
a examiné une correspondance avec les catégories de distribution énumérés, et
seuls les nouveaux forums qui correspondent seront listés. Si plus de
un groupe de distribution doit être énumérés, ils doivent être séparés par
virgules dans les équerres

S’il vous plaît noter que la liste vide (ie, le corps du texte retourné par cette
commande est composée uniquement de la période de fin) est un
possible valide
réponse, et indique qu’il ya actuellement pas de nouveaux forums..

3.7.2. Réponses

231 liste des nouveaux forums suit

>

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

3.8. La commande NewNews

3.8.1. NewNews

NewNews newsgroups date et l’heure [GMT] []

Une liste de message-ids des articles publiés ou reçus à l’
spécifiée
newsgroup depuis ‘date’ seront listés. Le format de la liste sera
être un message-id par ligne, comme si le texte a été envoyé. Un seul
ligne composée uniquement d’une période de suivi de CR-LF prendra fin
la liste

Date et heure sont dans le même format que la commande NEWGROUPS..

0

(S’il vous plaît noter que l’astérisque «*» est une expansion générale
remplacement, en particulier, le cahier des charges, par exemple,
net .*. unix
doivent être correctement élargi pour embrasser des noms tels que
net.wombat.unix
et net.whocares.unix.)

0

Le point d’exclamation (‘!’) peut être utilisée pour annuler un match. Cela peut
être utilisé de manière sélective omettre certains groupes de discussion à partir d’un
autrement
liste plus complète. Par exemple, une spécification de newsgroups
‘net .*, mod .*,! mod.map .*’de préciser que toutes les recettes nettes. et
tous les mod. SAUF mod.map. newsgroup noms seraient
appariés. Si elle est utilisée, le point d’exclamation doit apparaître comme le premier
caractère du nom de groupe de discussion ou un modèle donné.

Le paramètre optionnel ‘distributions’ est une liste de distribution
groupes, entourées de crochets pointus. Si spécifié, la distribution
partie du groupe de discussion d’un article (par exemple, «net» dans «net.wombat») sera
être examinés pour un match avec les catégories de distribution énumérés, et
seuls les articles qui ont au moins un groupe de discussion appartenant à

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

la liste des distributions seront listés. Si plus d’un
groupe de distribution doit être fourni, ils doivent être séparés par
virgules dans les équerres.

L’utilisation de la IHAVE, NewNews, et NEWGROUPS commandes de distribuer
nouvelles est discuté dans une partie précédente de ce document.

S’il vous plaît noter que la liste vide (ie, le corps du texte retourné par cette
commande est composée uniquement de la période de fin) est un
possible valide
réponse, et indique qu’il n’existe actuellement pas de nouvelles informations..

3.8.2. Réponses

230 liste des nouveaux articles par message-id suit

3.9. La commande NEXT

3.9.1. NEXT

NEXT

L’intérieur maintenu ‘pointeur actuel article»est avancé à
l’article suivant dans le groupe de discussion en cours. Si aucun des articles plus
rester dans le groupe actuel, un message d’erreur est retournée et la
l’actuel article reste sélectionné.

L’intérieur entretenu ‘pointeur actuel article’ est défini par le présent
commande.

Une réponse indiquant le numéro de l’article actuel, et le
message-id
string sera retournée. Aucun texte est envoyé en réponse à cette
commande.

3.9.2. Réponses

223 article na trouvé –
texte de la demande séparément
(numéro de l’article n =, un article unique id =)
412 pas de groupe de discussion sélectionné
420 pas de l’actuel article a été sélectionné
421 pas d’article suivant dans ce groupe

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

3.10. La commande POST

3.10.1. POST

POST

Si l’affichage est autorisé, 340 code de réponse est renvoyé pour indiquer que
l’article à être affiché doit être envoyée. Le code de réponse 440 indique
que l’affichage est interdit, pour une raison dépendant de l’installation.

Si l’affichage est autorisé, l’article devrait être présenté dans la
format spécifié par RFC850, et doit inclure tous les
nécessaire d’en-tête
lignes. Après l’article d’en-tête et le corps ont été complètement envoyé
par le client au serveur, un code de réponse ne sera retourné
pour indiquer la réussite ou l’échec de la tentative annonce.

Aucun effort ne doit être faite par le serveur pour filtrer les caractères, plier ou
des lignes de limite, ou tout autre traitement de texte entrant. Il est de notre intention
que le serveur vient de passer le message entrant à être envoyé sur les
installation serveur nouvelles annonce de logiciels, qui est distinct de
cette spécification. Voir RFC850 pour plus de détails.

223 article na trouvé –
texte de la demande séparément
(numéro de l’article n =, un article unique id =)
412 pas de groupe de discussion sélectionné
420 pas de l’actuel article a été sélectionné
421 pas d’article suivant dans ce groupe

Comme la plupart des installations se veulent l’émission de nouvelles client pour permettre
l’utilisateur de préparer son message en utilisant une sorte d’éditeur de texte, et
le transmettre au serveur pour afficher seulement après il est composé, l’
programme client doit prendre note du message héraut qui a accueilli il
lorsque la connexion a été établie. Ce message indique
déterminer si les inscriptions de ce client sont autorisés ou non, et peut être
utilisés pour prévenir l’utilisateur que son accès est en lecture seule si c’est le
cas. Cela permettra d’éviter à l’utilisateur de perdre une bonne partie de
temps
rédaction d’un message que de trouver l’affichage du message a été refusée.
La méthode et la détermination de laquelle les clients et les hôtes peuvent poste est
installation à charge et ne sont pas couverts par cette spécification.

3.10.2. Réponses

240 Article posté ok
Envoyer l’article 340 doit être affiché. Fin avec .
440 annonce pas autorisés
441 annonce a échoué

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

(pour référence, l’un des codes suivants seront envoyés sur
initial
connexion, le programme client doit déterminer si l’affichage est
généralement autorisé de ceux-ci:) 200 serveur prêt – annonce
permis
201 serveur prêt – Affichage interdit

3.11. La commande QUIT

3.11.1. QUIT

QUIT

Le processus serveur reconnaît la commande QUIT, puis ferme la
connexion avec le client. C’est la méthode préférée pour un client
pour indiquer qu’il a terminé toutes ses transactions avec le
NNTP
serveur.

Si un client se déconnecte tout simplement (ou le temps de connexion à, ou d’un
autre faute se produit), le serveur doit gracieusement cesser ses tentatives
au service du client.

3.11.2. Réponses

205 Fermeture de la connexion – au revoir!

3.12. La commande SLAVE

3.12.1. SLAVE

SLAVE

Indique au serveur que cette connexion client est un esclave
serveur, plutôt que d’un utilisateur.

Cette commande est destinée à séparer les connexions à
unique
usagers et ceux à la filiale («esclave») des serveurs. Il peut être utilisé pour
indiquer que la priorité devrait donc être accordée aux demandes provenant
ce client, car il est sans doute servir plus d’une personne. Il
pourrait également être utilisé pour déterminer les connexions à se fermer lorsque
les niveaux de charge du système sont dépassées, peut-être donner la préférence à
esclave
serveurs. L’utilisation effective de cette commande est mis à
entièrement
dépendant de l’implémentation, et peuvent varier d’un hôte à un autre. En
Serveurs NNTP qui ne donnent pas priorité aux serveurs esclaves, ce
commande doit néanmoins être reconnu et salué..

3.12.2. Réponses

202 le statut d’esclave a noté

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

4. Exemple Conversations

Ces échantillons sont des conversations qui pourraient être attendus avec
le serveur de nouvelles dans les sessions hypothétique. La notation C: indique
commandes envoyées au serveur de nouvelles du programme client; S: indiquer
réponses reçues à partir du serveur par le client.

4.1. Accès relatif avec NEXT – Exemple 1

S: (écoute sur le port TCP 119)

C: (demandes de connexion sur le port TCP 119)
S: 200 serveur de nouvelles wombatvax prêt – affichage ok

(client demande une liste de groupes de discussion en cours)
C:
LISTE
S: 215 liste des groupes de discussion suit
Net.wombats 00543 00501
y: S
S: net.unix-assistants 10125 10011
y
(plus d’informations ici)
S: net.idiots 00100 00001
n
S: .

(client sélectionne un groupe de discussion)
C: GROUPE net.unix-assistants
S: 211 104 1001 1 groupe de 10 125 net.unix-assistants choisis
(il ya 104 articles dans le dossier, de 10011 à 10125)

(client choisit un article à lire)
C: STAT 10110
S: 223 10110 <[email protected]> Article extrait –
statistiques
seulement (art. 10110 sélectionné, son message-id est
<[email protected]>)

(client examine l’en-tête)
C:
HEAD
S: 221 10110 <[email protected]> Article extrait –
tête
suit (le texte de l’en-tête apparaît ici)
S:.

(client veut voir le corps du texte de l’article)
C:
CORPS
S: 222 10110 <[email protected]> Article extrait –
corps
suit (le corps du texte ici)
S:

(client sélectionne l’article suivant dans le groupe)
.

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

C:
NEXT
S: 223 10113 article <[email protected]> récupéré –
statistiques
seulement (art. 10113 était à côté dans le groupe)

(client termine la session)
C: QUIT
S: 205 au revoir.

4.2. Exemple 2 – accéder à l’article absolue ARTICLE

S: (écoute sur le port TCP 119)

C: (demandes de connexion sur le port TCP 119)
S: 201 UCB-VAX netnews serveur prêt – Affichage interdit

C: GROUPE
msgs
S: 211 103 402 504 msgs Votre nouveau groupe est
msgs
(il ya 103 articles, 402 à 504)

C: l’article 401
S: 423 N ° tel article dans ce groupe de discussion

C: ARTICLE 402
S: 220 402 <[email protected]> Article trouvé, le texte suit
S: (en-tête et le corps l’article ci-après)
S: ..

C: TETE 403
S: 221 403 <[email protected]> Article récupéré, tête suit
S: (en-tête de l’article ci-dessous)
S:

C: QUIT
S: 205 nouvelles UCB-VAX serveur fermeture de la connexion. Au revoir.

4.3. Exemple 3 – commande NEWGROUPS

S: (écoute sur le port TCP 119)

C: (demandes de connexion sur le port TCP 119)
S: 200 Imaginary Nouvelles de l’Institut Server prêt (affichage ok)

(client demande des groupes de discussion de nouvelles depuis le 3 avril 1985)
C: NEWGROUPS 850403 020000

S: 231 groupes de discussion de la situation depuis 03/04/85 02:00:00 suivi

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

S:
net.music.gdead
S: net.games.sources
S:

C: GROUPE net.music.gdead
S: 211 0 1 1 net.music.gdead
Newsgroup sélectionnés
(il n’y a pas d’articles dans ce groupe de discussion, et
les numéros article premier et le dernier doit être ignorée)

C: QUIT
S: 205 service Imaginary Institut serveur de nouvelles cesse. Bye!

4.4. Exemple 4 – annonce un article de nouvelles

S: (écoute sur le port TCP 119)

C: (demandes de connexion sur le port TCP 119)
S: 200 serveur BANZAIVAX nouvelles prêt, annonce autorisés..

C:
POST
S: 340 Continuer annonce; période sur une ligne par lui-même de mettre fin à
C:
(article de nouvelles transmet au format RFC850)
C:.
S: 240 Article publié avec succès..

C: QUIT
S: 205 fermeture de la connexion BANZAIVAX. Au revoir.

4.5. Exemple 5 – interruption due à la demande de l’opérateur

S: (écoute sur le port TCP 119)

C: (demandes de connexion sur le port TCP 119)
S: 201 serveur de nouvelles genericvax prêt, aucune annonce autorisés

(en supposant une conversation normale pendant un certain temps, et
qu’un groupe de discussion a été sélectionné)

C:
NEXT
S: 223 1013 <[email protected]> Article récupérées; texte séparé.

C:
HEAD
C: 221 1013 <[email protected]> Article récupéré, la tête suit..

S: (envoie la tête de l’article, mais à mi-parcours est
interrompue par une demande de l’opérateur. Le
suivantes
Il se produit alors, sans intervention du client.)

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

S: (extrémités de la ligne actuelle avec une paire CR-LF)
S:.
S: 400 Connexion fermée par l’opérateur. Goodbye.
S: (connexion se ferme)

4.6. Exemple 6 – Utilisation du serveur de nouvelles pour distribuer des nouvelles entre
systèmes

S: (écoute sur le port TCP 119)

C: (demandes de connexion sur le port TCP 119)
S: 201 Foobar serveur NNTP prête (pas d’affichage)

(client demande des groupes de discussion de nouvelles depuis deux heures, le 15 mai 1985)
C: NEWGROUPS 850515 020000
S: 235 groupes de discussion de la situation depuis 850515 suivi
S:
net.fluff
S:
net.lint
S:

(client demande pour les articles de nouvelles nouvelles depuis deux heures, le 15 mai 1985)
C: NewNews * 850515 020000
S: 230 nouvelles Nouveau depuis 850 515 020 000 suit
S: /> <[email protected]>
<[email protected]>

S:

(client demande l’article <[email protected]>)
C: ARTICLE /> <[email protected]>
Tous de l’article suit
S: (envoie le message en entier)
S:

(client demande l’article
/>
C: ARTICLE /> <[email protected]>
Tous de l’article suit
S: (envoie le message en entier)
S: ..

(client demande l’article <[email protected]>
C: ARTICLE /> <[email protected]>
Tous de l’article suit
S: (envoie le message en entier)
S:.

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

(client offre un article qu’il a reçu récemment)
C: IHAVE <[email protected]>
S: 435 Déjà vu celui-là, où tu étais?

(client offre un autre article)
C: IHAVE <[email protected]>
S: 335 Nouvelles pour moi! à la fin.
C:
(envoie l’article)
C:.
S: 235 Article transférés avec succès. Merci.

(ou)

S: 436 Échec du transfert.

(client tout au long de la session)
C: QUIT
S: 205 offres Foobar serveur NNTP vous dire adieu

4.7. Résumé des commandes et des réponses

Ce qui suit sont les commandes reconnues et les réponses renvoyées par
le serveur NNTP.

4.7.1. Commandes

ARTICLE

CORPS

GROUPE

HEAD
HELP

IHAVE

DERNIER

LISTE
NEWGROUPS

NewNews

NEXT

POST

QUIT

SLAVE
STAT

4.7.2. Réponses

100 suit le texte d’aide
199 sortie de débogage

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

200 serveur prêt – Affichage interdit
201 serveur prêt – pas
annonce a permis
202 le statut d’esclave a noté
205 Fermeture de la connexion – revoir
!
211 n f l s
groupe sélectionné
215 liste des groupes de discussion suit
Article 220 n récupérés – tête et le corps suivent 221 n
article
Récupérée – tête suit
222 n article trouvé – corps suit
223 Article n extrait – texte demande séparément la liste des 230
nouvelles
articles par message-id suit
231 liste des nouveaux forums suit
235 article cédé ok
240 Article posté ok

 

335 article envoyer à être transféré. Fin avec .
Envoyer l’article 340 doit être affiché. Fin avec .

400 service interrompu
411 pas de tel
des nouvelles du groupe
412 pas de groupe de discussion a été sélectionné
420 pas de l’actuel article a été sélectionné
421 pas d’article suivant dans ce groupe
422 sans précédent article de cette
groupe
423 pas de numéro de tel article dans ce groupe
430 pas de tel article trouvé
435 article ne voulait pas – ne pas envoyer
436 Echec du transfert – essayez plus tard
437 article rejeté – ne pas essayer de nouveau
.
440 annonce pas autorisés
441 annonce a échoué

500 commande non reconnue
501 commande
erreur de syntaxe
502 de restriction d’accès ou permission refusée
503 erreur de programme – commande pas effectué

 

4.8. Un bref mot sur le système Usenet Nouvelles

Dans le monde UNIX, qui a toujours été liée en 1200
bauds
ligne d’appel téléphonique, le système USENET Nouvelles a évolué pour gérer
stockage centralisé, l’indexation, l’extraction et la distribution des nouvelles. Avec
l’exception de son mécanisme de transport sous-jacent (UUCP),
USENET
Nouvelles est un moyen efficace de fournir un service de nouvelles et le bulletin d’
abonnés sur UNIX et d’autres hôtes à travers le monde. Le
Nouvelles Usenet

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

système est discuté en détail dans la RFC 850. Il fonctionne sur la plupart des versions
d’UNIX et sur ​​de nombreux autres systèmes d’exploitation, et est habituellement
distribué gratuitement.

USENET utilise une zone de file d’attente sur l’hôte UNIX pour stocker articles de nouvelles,
un par fichier. Chaque article est constitué d’une série de position du texte,
qui contiennent l’identification de l’expéditeur et
organisation
timestamps affiliation, électroniques chemins réponse par courrier, sous réserve,
groupe de discussion (catégorie de sujet), etc. A
nouvelles compléter l’article
est reproduit dans son intégralité ci-dessous. S’il vous plaît consulter la RFC 850 pour plus
détails

Relais-Version: Version B 2.10.3 4.3BSD-beta 6/6/85;
site

sdcsvax.UUCP
Signalisation-Version: Version B 2.10.1 6/24/83 SMI;
site unitek.uucp
Sentier:! sdcsvax sdcrdcf hplabs qantel ihnp4 alberta ubc-vision Unitek
!!
!
honman
De: [email protected] (Man Wong)
Groupes de discussion:
net.unix-assistants
Objet: premier plan – arrière-plan>
?
Message-ID: /> <[email protected]>

Date-Reçu: 29 septembre 85 09:54:48 GMT
Reply-To: [email protected] (Hon-Man Wong)
Distribution: net.all
Organisation: Unitek
Technologies Corporation
Lignes: 12

J’ai un processus (programme C) qui génère un enfant et attend
qu’il revienne. Ce que je voudrais faire est d’être en mesure d’exécuter la
processus de l’enfant de manière interactive pendant un certain temps avant de se coup de pied dans
l’arrière-plan afin que je puisse revenir au processus parent (alors que la
processus fils est en arrière-plan). Peut-il être fait? Et
s’il le peut, comment?

S’il vous plaît réponse par E-mail. Merci d’avance

Hon-Man Wong

RFC 977 Février 1986
Nouvelles du Réseau de transfert
Protocole

5. Références

Crocker [1], D., ‘Norme pour le format de l’ARPA Internet
Texte
Messages ‘, RFC-822, Département de génie électrique,
Université du Delaware, août 1982

[2] Horton, M., ‘Standard pour l’échange de messages Usenet’,
RFC-850, projet USENET, Juin, 1983.

Postel [3], J., « Control Transmission Protocol-DARPA Internet
Spécification du protocole du programme « , RFC-793, USC / Information
Institut des Sciences, Septembre 1981

[4] J. Postel, « Simple Mail Transfer Protocol », RFC-821,
USC / Information Sciences Institute, août 1982..

6. Remerciements

Les auteurs tiennent à exprimer leurs sincères remerciements à ceux de nombreux
personnes qui ont contribué à cette spécification, et surtout à
Erik
Fair et le CHUQ von Rospach, dont l’inspiration sans cette
toute chose
n’aurait pas été nécessaire.

7. Notes

<1> UNIX est une marque déposée de Bell Laboratories.