1. Field of the Invention
The present invention relates to performing multiple packet User Datagram Protocol (UDP) transfers using pseudo domains and pseudo IP addresses.
2. Description of the Related Art
The Internet uses a set of communications protocols that implement the protocol stack on which the Internet and most private networks run. Two of the most important protocols used on the Internet and on private networks are the Transmission Control Protocol (TCP) and the Internet Protocol (IP), which were also the first two networking protocols defined. Another common protocol used on the Internet and on private networks is the User Datagram Protocol (UDP). Using UDP, programs on networked computers can send short messages, known as datagrams, to one another. There are also a number of other protocols that are commonly, or less commonly used on the Internet and on private networks.
Typically, certain network applications have tended to use particular protocols, due to differences in complexity and capability of the various protocols. For example, accesses to Domain Name Servers (DNSs) are typically performed using UDP. Most DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. UDP is relatively simple to implement, but is capable of handling single packet messages with no more than 512 bytes of data. If the data size of the response from the DNS exceeds 512 bytes, then most DNSs will attempt to use TCP to send the response, as TCP is capable of handling larger packets and multi-packet messages. However, TCP is considerably more complex than UDP, and many DNS clients cannot correctly switch to using TCP when the DNS response messages are sent using TCP.
A need arises for a technique by which UDP can be used to send messages that include more data than can be handled by a single UDP packet.
The present invention provides a technique by which UDP can be used to send messages that include more data than can be handled by a single UDP packet. A method for performing data transfer implemented in a computer system comprises transmitting a request for data, receiving a response to the request for data comprising a portion of the requested data and an indication that additional data is available, and transmitting a request for additional data. The method may use User Datagram Protocol. The transmitted request for data may include a domain. The transmitted request for data may comprise a lookup request for a domain sent to a Domain Name Server Blacklist/Real-Blackhole List. The response may further comprise a pseudo-Internet Protocol address. The pseudo-Internet Protocol address may comprise the indication that additional data is available. The request for additional data may comprise a pseudo-domain indicating that additional data is being requested. The response to the request for data further may comprise an indication of an amount of the additional data that is available. The response may further comprise a pseudo-Internet Protocol address. The pseudo-Internet Protocol address may comprise the indication of the amount of the additional data that is available.
A method for performing data transfer implemented in a computer system comprises a) transmitting a request for data using User Datagram Protocol, b) receiving a response to the request for data using the User Datagram Protocol, the response comprising a portion of the requested data that fits in a User Datagram Protocol packet and an indication that additional data is available, c) transmitting a request for additional data using the User Datagram Protocol, and d) repeating steps h) c) until a response is received indicating that no additional data is available. The transmitted request for data may include a domain. The transmitted request for data may comprise a lookup request for a domain sent to a Domain Name Server Blacklist/Real-time Blackhole List. The response may further comprise a pseudo-Internet Protocol address. The pseudo-Internet Protocol address may comprise the indication that additional data is available. The request for additional data may comprise a pseudo-domain indicating that additional data is being requested. The response to the request for data further may comprise an indication of an amount of the additional data that is available. The response may further comprise a pseudo-Internet Protocol address. The pseudo-Internet Protocol address may comprise the indication of the amount of the additional data that is available.
A method for performing data transfer implemented in a computer system comprises transmitting a request for data using User Datagram Protocol, receiving a response to the request for data using the User Datagram Protocol, the response comprising a portion of the requested data that fits in a User Datagram Protocol packet and an indication of an amount of additional data that is available, and transmitting a number of requests for additional data using the User Datagram Protocol, the number of requests based on the amount of additional data that is available. The transmitted request for data may include a domain. The transmitted request for data may comprise a lookup request for a domain sent to a Domain Name Server Blacklist/Real-time Blackhole List. The response may further comprise a pseudo-Internet Protocol address. The pseudo-Internet Protocol address may comprise the indication of the amount of additional data that is available. The request for additional data may comprise a pseudo-domain indicating the amount of additional data that is available.
The details of the present invention, both as to its structure and operation, can best be understood by referring to the accompanying drawings, in which like reference numbers and designations refer to like elements.
The present invention provides a technique by which UDP can be used to send messages that include more data than can be handled by a single UDP packet by
Coupled to the networks 102 are server computers 104 which are capable of communicating over the networks 102. Also coupled to the networks 102 and the server computers 104 is a plurality of client computers 106. Such server computers 104 and/or client computers 106 may each include a domain name service (DNS) server, desktop computer, lap-top computer, hand-held computer, mobile phone, hand-held computer, peripheral (e.g. printer, etc.), any component of a computer, and/or any other type of logic. In order to facilitate communication among the networks 102, at least one gateway or router 108 is optionally coupled therebetween.
A Domain Name System (DNS) associates various sorts of information with called domain names and it serves as the “phone book” for the Internet. The DNS translates human-readable computer hostnames into the IP addresses that networking equipment needs for delivering information. DNSs also store other information. One such type of information is known as a DNS Blacklist (DNSBL) or Real-time Blackhole List (RBL). A DNSBL or RBL DNS functionality is a means by which an Internet site may publish a list of IP addresses that some people may want to avoid and in a format which can be easily queried by computer programs on the Internet. The technology is built on top of the Internet Domain Name System, or DNS. DNSBLs are chiefly used to publish lists of addresses linked to spamming or phishing. Most mail transport agent (mail server) software can be configured to reject or flag messages which have been sent from a site listed on one or more such lists.
DNSBL/RBL DNS functions commonly use pseudo IP addresses to indicate the status of a domain. For example, a response from a DNSBL/RBL may include a pseudo IP address that includes information about the status of transactions, information identifying electronic content, etc. This mechanism may also be used to send messages or responses that include more data than can be handled by a single UDP packet. An example of such a process 200 is shown in
If octet 402-1 is treated as a bit field including bits 404-1 to 404-8, then bits 404-1, 404-4 and 404-7 are set in this example. Bit 404-1 indicates there is a text record, bit 404-4 indicates that the domain hosts a suspect phish site, and bit 404-7, for the purposes of this invention, indicates that the text record is incomplete. Bit 404-7 being set here then means that the client should do a further lookup for this request. Thus, in step 206, it is determined that additional data is available for this request. In step 208, a request 310 for the next portion of the data for the request is sent including a pseudo domain such as “phishy.domain.1.spamrbl.mcafee.com”. Process 200 then loops to step 204, in which the next response is received. This response 312 might also return “127.0.0.73”. Again, bit 7 being set means that a further lookup would yield more information, so the client would query for another pseudo domain, such as “phishy.domain.2.spamrbl.mcafee.com”, and so on until the response 314 no longer had bit 7 set, such as “127.0.0.03”. When step 206 determines that no more data is available, process 200 ends.
In this example, the pseudo domain sequence would thus be:
Variations on the above-described process are possible as well. For example, if it is known in advance how many requests would be needed, the client could send all the secondary partial requests at once rather than serially. This could be encoded in another part of the returned IP address.
For example, a query on foo.bar.rbl.mcafee.com using the above-described process may return:
In this example, there are three further requests that could be made to get the complete data. This can be encoded in the returned IP address by returning the court in the next most significant byte:
The first request would thus allow the client to initiate the next three requests concurrently without waiting for a response, which would save time.
It is to be noted that the examples described above, of using multiple requests to obtain responses to DNSBL/RBL lookups that are larger than will fit in one UDP packet, is merely an example of the multiple request mechanism of the present invention. Rather, the present invention contemplates usage in any situation in which the quantity of data to be transferred is greater than will fit in a single UDP packet.
An exemplary block diagram of a computer system 500, in which the present invention may be implemented, is shown in
Input/output circuitry 504 provides the capability to input data to, or output data from, computer system 500. For example, input/output circuitry may include input devices, such as keyboards, mice, touchpads, trackballs, scanners, etc., output devices, such as video adapters, monitors, printers, etc., and input/output devices, such as, modems, etc. Network adapter 506 interfaces computer system 500 with Internet/intranet 510. Internet/intranet 510 may include one or more standard local area network (LAN) or wide area network (WAN), such as Ethernet, Token Ring, the Internet, or a private or proprietary LAN/WAN.
Memory 508 stores program instructions that are executed by, and data that are used and processed by, CPUs 502A-N to perform the functions of computer system 500. Memory 504 may include electronic memory devices, such as random-access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), flash memory, etc., and electro-mechanical memory, such as magnetic disk drives, tape drives, optical disk drives, etc., which may use an integrated drive electronics (IDE) interface, or a variation or enhancement thereof, such as enhanced IDE (EIDE) or ultra direct memory access (UDMA), or a small computer system interface (SCSI) based interface, or a variation or enhancement thereof, such as fast-SCSI, wide-SCSI, fast and wide-SCSI, etc, or a fiber channel-arbitrated loop (FC-AL) interface.
The contents of memory 508 varies depending upon the function that computer system 500 is programmed to perform. In the example shown in
As shown in
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include storage media, examples of which include, but are not limited to, floppy disks, hard disk drives, CD-ROMs, DVD-ROMs, RAM, and, flash memory, as well as transmission media, examples of which include, but are not limited to, digital and analog communications links.
Although specific embodiments of the present invention have been described, it will be understood by those of skill in the art that there are other embodiments that are equivalent to the described embodiments. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrated embodiments, but only by the scope of the appended claims.
This Application is a continuation (and claims the benefit of priority under 35 U.S.C. §120) of U.S. application Ser. No. 11/898,853, filed Sep. 17, 2007, now U.S. Pat. No. 8,219,686 entitled “METHOD AND COMPUTER PROGRAM PRODUCT UTILIZING MULTIPLE UDP DATA PACKETS TO TRANSFER A QUANTITY OF DATA OTHERWISE IN EXCESS OF A SINGLE UDP PACKET,” Inventor(s) John Sargent, et al.. The disclosure of the prior application is considered part of (and is incorporated by reference in) the disclosure of this application.
Number | Name | Date | Kind |
---|---|---|---|
5987610 | Franczek et al. | Nov 1999 | A |
6073142 | Geiger et al. | Jun 2000 | A |
6460050 | Pace et al. | Oct 2002 | B1 |
7506155 | Stewart et al. | Mar 2009 | B1 |
7620733 | Tzakikario et al. | Nov 2009 | B1 |
20020184390 | Alkhatib | Dec 2002 | A1 |
20040010616 | McCanne | Jan 2004 | A1 |
20050047329 | Almog et al. | Mar 2005 | A1 |
20060056403 | Pleasant et al. | Mar 2006 | A1 |
20070073660 | Quinlan | Mar 2007 | A1 |
20090074008 | Sargent et al. | Mar 2009 | A1 |
Entry |
---|
Extension Mechanism for DNS, Network Working Group, RFC (Request for Comment) 2671, P. Vixie, Aug. 1999. |
Welch, et al., “Pseudo-File-Systems,” Oct. 1989, Computer Science Division, Electrical Engineering and Computer Sciences, University of California. |
Number | Date | Country | |
---|---|---|---|
20120246274 A1 | Sep 2012 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11898853 | Sep 2007 | US |
Child | 13490156 | US |