[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Functions for sending binary over FTp
Date: Thu, 26 Jul 90 17:41 PDT
From: Reti@STONY-BROOK.SCRC.Symbolics.COM (Kalman Reti)
Date: Mon, 23 Jul 90 17:27:43 MDT
From: email@example.com (David R Strip )
Are there equivalent functions to the Un*x NTOHS and HTONS, etc?
What are NTOHS and HTONS? On the Lispm FTP is treated like any other
file protocol, i.e. you can copy binary files with COPY FILE if you
specify :MODE binary :BYTE-SIZE 8 [or :element-type '(unsigned-byte 8)]
if you do the copying programmatically either with COPY-FILE or as
an open option.
Functions with names of the form hton<char> and ntoh<char> are used to
convert integers (<char> is "s" for a short (16-bit) or "l" for a long
(32-bit)) between host and network format. On systems whose native byte
order is different from that used in TCP/IP protocols these routines
perform byte swapping; on systems with the same byte order as the network
protocols they are identity functions.
Using COPY-FILE with the :BYTE-SIZE option is fine if the file is intended
to be read later by the same system that wrote it. But if the result is
intended to be read by other systems the data needs to be converted to a
common format. Network byte order is a commonly-implemented format, since
all systems that implement TCP/IP must have some routines for doing this
I think the equivalents to ntohs and ntohl are TCP::IP-LOAD-16 and
TCP::IP-LOAD-32, and the equivalents to htons and htonl are
TCP::IP-STORE-16 and TCP::IP-STORE-32. Since they are designed for
interfacing with network packets, they take an (unsigned-byte 8) array and
an index to specify where the network order data is to be loaded/stored.
Needless to say (but I'll say it anyway) these routines are internal and
undocumented, hence subject to change by Symbolics without notice.