menqjuh@grad1.cis.upenn.edu (Menq J. Lee) (11/28/90)
Hi everybody,
I am new to this field, and I am using DGRAM Socket (UDP) to build a remote
copy utility. This utility supports both ascii and binary file transfers.
I have no problem in handling binary transfer. But when it comes to ascii
transfer, the reference I read told me that I must take care of some
critical cases. Specifically, I have to do some conversion between
newline <---> CR,LF (Carriage Return, Line Feed)
CR <---> CR,NULL
I have the following questions about this issue:
1. Why is this necessary? In other words, under what situations
will this conversion be employed to avoid foreseeable errors?
2. Do I have to do the same conversion if I use STREAM Socket (TCP)
instead of DGRAM Socket?
Any help will be highly appreciated.
--Menqenag@ifi.uio.no (Erik Naggum) (11/29/90)
In article <33562@netnews.upenn.edu>, Menq J. Lee writes:
I am new to this field, and I am using DGRAM Socket (UDP) to build
a remote copy utility. This utility supports both ascii and binary
file transfers.
You may find that FTP [1] does what you need, albeit with a little more
overhead. FTP uses TCP, because it doesn't want to bother with
retransmission, congestion problems, etc. Neither should you. For a
local area network remote copy utility, there exists the Berkeley Unix
system rcp(1). I believe it's freely available from Berkeley source
repositories like UUNET.UU.NET via anonymous FTP. It's not recommended
between different users because of security related deficiencies.
You may also look into NFS [2] if this is part of a file system design.
You may want to look at TFTP [3] for a very simple approach to file
transfer and remote file copying.
I have no problem in handling binary transfer. But when it comes to
ascii transfer, the reference I read told me that I must take care
of some critical cases. Specifically, I have to do some conversion
between
newline <---> CR,LF (Carriage Return, Line Feed)
CR <---> CR,NULL
I have the following questions about this issue:
1. Why is this necessary? In other words, under what
situations will this conversion be employed to avoid
foreseeable errors?
It is necessary because you want to relieve your client under operating
system X from knowing about the line termination conventions of
operating system Y. This becomes progressively more pressing for large
sets of operating systems and conventions.
2. Do I have to do the same conversion if I use STREAM
Socket (TCP) instead of DGRAM Socket?
Yes. You have to do a lot less work if you start using TCP, though.
-----
[1] RFC 959 File Transfer Protocol. (See also RFC 1068 Background
File Transfer Program.)
[2] RFC 1094 NFS: Network File System Protocol Specification
[3] RFC 783 TFTP Protocol (revision 2)
--
[Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions. Wail: +47-2-836-863
--e85rw@efd.lth.se (Ricard Wolf) (11/29/90)
In article <ENAG.90Nov29005054@hild.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >In article <33562@netnews.upenn.edu>, Menq J. Lee writes: .... > > I have no problem in handling binary transfer. But when it comes to > ascii transfer, the reference I read told me that I must take care > of some critical cases. Specifically, I have to do some conversion > between > > newline <---> CR,LF (Carriage Return, Line Feed) > CR <---> CR,NULL > > I have the following questions about this issue: > > 1. Why is this necessary? In other words, under what > situations will this conversion be employed to avoid > foreseeable errors? > >It is necessary because you want to relieve your client under operating >system X from knowing about the line termination conventions of >operating system Y. This becomes progressively more pressing for large >sets of operating systems and conventions. If you use FTP in the ascii transfer mode (whcih is the default) this is taken care of automagically. -- Ricard Wolf +--------------------------+-------------------------------------+ | Ricard Wolf | Lund Institute of Technology | | email: e85rw@efd.lth.se | If you can't buy 'em - build 'em !! | +--------------------------+-------------------------------------+