Discard Protocol: Difference between revisions
Copy edit. Avoid the construction "and/or" per MOS:ANDOR. →See also: Rm duplicate links per MOS:DUPLINK. Alphabetize per MOS:SEEALSO. |
m added author, year of publication and a proper link to the rfc |
||
| (8 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Internet protocol that discards all input}} |
|||
{{multiple issues| |
{{multiple issues| |
||
{{no footnotes|date=October 2014}} |
{{no footnotes|date=October 2014}} |
||
| Line 5: | Line 6: | ||
{{IPstack}} |
{{IPstack}} |
||
The '''Discard Protocol''' is a service in the [[Internet Protocol Suite]] defined in |
The '''Discard Protocol''' is a service in the [[Internet Protocol Suite]] defined in 1983 in {{IETF RFC|863}} by [[Jon Postel]]. It was designed for testing, debugging, measurement, and host-management purposes. |
||
A host may send data to a host that supports the Discard Protocol on either [[Transmission Control Protocol]] (TCP) or [[User Datagram Protocol]] (UDP) [[port number]] 9. The data sent to the server is simply discarded. No response is returned. For this reason, UDP is usually used, but TCP allows the services to be accessible on session-oriented connections (for example via [[Hypertext Transfer Protocol|HTTP]] proxies or some [[virtual private network]] (VPN)). |
A host may send data to a host that supports the Discard Protocol on either [[Transmission Control Protocol]] (TCP) or [[User Datagram Protocol]] (UDP) [[port number]] 9. The data sent to the server is simply discarded. No response is returned. For this reason, UDP is usually used, but TCP allows the services to be accessible on session-oriented connections (for example via [[Hypertext Transfer Protocol|HTTP]] proxies or some [[virtual private network]] (VPN)). |
||
| Line 22: | Line 23: | ||
* [[Daytime Protocol]] |
* [[Daytime Protocol]] |
||
* [[Time Protocol]] |
* [[Time Protocol]] |
||
== References == |
|||
{{Reflist}} |
|||
== External links == |
== External links == |
||
* RFC 348, the Discard Process |
* [https://www.rfc-editor.org/rfc/rfc348 RFC 348], the Discard Process |
||
* RFC 863, the Discard Protocol |
* [https://www.rfc-editor.org/rfc/rfc863 RFC 863], the Discard Protocol |
||
[[Category:Application layer protocols]] |
[[Category:Application layer protocols]] |
||
{{Internet-stub}} |
|||
Latest revision as of 19:27, 15 June 2024
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
|
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
The Discard Protocol is a service in the Internet Protocol Suite defined in 1983 in RFC 863 by Jon Postel. It was designed for testing, debugging, measurement, and host-management purposes.
A host may send data to a host that supports the Discard Protocol on either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port number 9. The data sent to the server is simply discarded. No response is returned. For this reason, UDP is usually used, but TCP allows the services to be accessible on session-oriented connections (for example via HTTP proxies or some virtual private network (VPN)).
Inetd implementation
[edit]On most Unix-like operating systems a discard server is built into the inetd (or xinetd) daemon. The discard service is usually not enabled by default. It may be enabled by adding the following lines to the file /etc/inetd.conf and reloading the configuration:
discard stream tcp nowait root internal discard dgram udp wait root internal
The Discard Protocol is the TCP/UDP equivalent of the Unix file-system node /dev/null. Such a service is guaranteed to receive what is sent to it and can be used for debugging code requiring a guaranteed reception TCP or UDP payloads.
On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake them up remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).
See also
[edit]External links
[edit] | This Internet-related article is a stub. You can help Wikipedia by expanding it. |