HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (peter da silva)
Subject: Re: what does completion of write() really mean?
Organization: Xenix Support, FICC
Distribution: usa
Date: Tue, 6 Oct 1992 14:54:26 GMT

In article <1992Oct5.163538.26590@PA.dec.com> mohanram@wsl.dec.com (Narayan Mohanram) writes:
> I agree with this. The sematics of write (or send) should be associated with
> data going out completely.

They never have been, on UNIX. On VMS, where these semantics are guaranteed,
we get horrible network performance on OSI as the stack manfully attempts to
keep all the write borders intact all the way through to the ether.

I'd rather a "complete write" function at the system call level (fsync)
for the cases where it matters, instead of forcing all I/O to complete
before a write returns.

It's not a networking problem, and shouldn't be addressed at the networking
level. That's how we got UNIX networking in the mess it is in the first place.
-- 
Peter da Silva                                          `-_-'
Ferranti Intl. Ctls. Corp.                               'U` 
Sugar Land, TX  77487-5012           "Heeft u vandaag al uw wolf geknuffeld?"
+1 713 274 5180            "Dat is mijn gezel, en niet bedoeld als een fooi."
Newsgroups: comp.protocols.tcp-ip,aus.wanted
From: merce@xenitec.on.ca (Jim Mercer)
Subject: Re: AS400s and Suns together
Organization: Reptilian Research, Kitchener, Ontario, CANADA
Date: Sun, 11 Oct 1992 05:30:19 GMT

In article <elogan.718304279@mistxt.oc.com> elogan@mistxt.oc.com (Ernie Logan) writes:
>merce@xenitec.on.ca (Jim Mercer) writes:
>
>>telnet into the AS/400 requires tn3270 or tn5250 (the latter is hard to find).
>
>Well, Jim, I tend to agree with most of what you said, except that TN5250
>is hard to come by. You only need to email info@oc.com, or call or write:

hmmm, you forgot your smiley.

when there is basically only one source, and a commercial one, for a telnet
flavour, i would call that hard to come by.

8^)

i have a demo version of the Open Connect TN5250 for MSDOS, which i have not
had a chance to try out yet.  (RSN now, as the boss is getting a little
impatient).

my only bitch about this product (which i have not tried), and others like
it, is that it is only available for specific TCP/IP stacks.

why can you not produce one for those of us (especially in the academic
world) that don't use a specific kernel (ie. FTP, B&W, LWP, etc).

can you not put a TCP kernel in your product?

if not, i know someone who would do it as a piece work contract.  8^)

another note:  we have just received a blurb from IBM about the "new"
release, which will support incoming VT100 (yeaaa!!!) and outgoing VT100
telnet sessions (how is this done on a block mode terminal?)

ernie, maybe you can give us some technical info that would be real useful.

how many sessions will the current and "new" versions support? (incoming)

also, how much of a load does telnet put on the system, compared to say
PC Support, which don't work worth a shit over ethernet (ok, it works, but
it requires the MSDOS workstation to run ODI, NDIS and LANSUP all at once,
not to mention that the terminal emulation is only implemented as a TSR,
so you need bazillions of spare bytes.)

answer these simple questions, and you'll build up some USENET karma points.

[ disclaimer: it's Sunday morning, at 1:30 AM, and i was out octoberfesting,
  so the format of this article may not follow my norms. ]

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]
From: mc@math.math.mv.dupont.com (Matt Cunningham-Software Development)
Newsgroups: comp.protocols.tcp-ip
Subject: netmask - SUN/SPARC
Keywords: netmask
Date: 8 Oct 92 20:53:43 GMT
Distribution: usa
Organization: DuPont EOP, Morrisville, NC

I need to determine the netmask of say 'le0' from inside a program.  I know the
'ifconfig' command will do this for me from the command line but as I said I 
must do it from in my program.  I am aware there is an ioctl SIOCGIFNETMASK
that is supposed to get the netmask for me however the specifics of how to use
the ioctl and what structure it places the info in is not known to me.  Can
anyone shed some light on this problem and possibly explain how these ioctls
work.  I'm working on a SUN/SPARC station using SUNOS 4.1.1.


							THANKS
							Matt Cunningham
							mc@mv.dupont.com
Newsgroups: comp.protocols.tcp-ip
From: johnr@pacdata.uucp (John Reed)
Subject: Re: TCP/IP Printers.
Organization: Pacific Data Products
Date: Wed, 7 Oct 1992 23:51:24 GMT

In article <2480015@hprnd.rose.hp.com> k@hprnd.rose.hp.com (Steve Kao) writes:
>Timothy Lange:
>> I'm looking for a TCP/IP ready printer to connect via Ethernet.  I
>> have seen lots of IPX and Appletalk ready printers but none for TCP/IP
>> (lpd).  Has anyone seen such a machine?
>
>HP has several printers that work over tcp/ip.  For LaserJets II, IID,
>III, and IIID, you can get either the C2071S (for twisted-pair) or
>C2071T (for Thin co-ax) cards for the printer.  The LaserJet IIISi, you
>can get the C2059T card.
>
>QMS also has a tcp/ip printer.
>
>- Steve Kao

For the price of a used Sun3/50 (diskless, 4 Megs Ram, no monitor = $175.00
from Minicomputer Exchange), and a little software work, you can easily make
your own.

I just wrote both a tftp server and an lpd server that execute on top
of Xinu (version 7.9 from Purdue), which runs natively on the 3/50.

Together with a memory spooler, I have a very nice tcp/ip print
server/spooler.

I connect ttyb to the Laser Printer serial port (19200 baud), and have
ttya (the Xinu console) wired into a 16-channel Mux of another computer.

My lpd server currently handles 4 connections (controlled by a #define),
with one of the connections reserved for non-data messages (like lpq or lprm).
My tftp server handles only 1 connection.

Anyone who is interested in the details, please ask.



JR



-- 


   /------------------------------------------------------------------\
  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
  |  Pacific Data Products               johnr@pacdata.com             |
  |                    ---------------------                           |
  |  George Herbert Walker Bush, with the letters re-arranged spells:  |
  |                                                                    |
  |                 Huge Berserk Rebel Warthog                         |
  |                                     -- From Cosmic Trigger II      |
   \------------------------------------------------------------------/
From: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCPIP for VAX/VMS
Date: 9 Oct 92 19:04:00 GMT
Reply-To: gavron@ACES.COM
Organization: ACES Consulting Inc.
News-Software: VAX/VMS VNEWS 1.4-b1

In article <2810@bsu-cs.bsu.edu>, sam@bsu-cs.bsu.edu (B. Samuel Blanchard) 
writes...
#In article <1aup88INN8vn@huon.itd.adelaide.edu.au> dclunie@sirius.ucs.adelaide.edu.au (David Clunie) writes:
#>
#>We have an old Seimens MRI scanner based on a Dec VAX 750 that we want
#>to put on an ethernet running TCP/IP to Suns and so on.
# 
#>David Clunie (dclunie@itd.adelaide.edu.au)
# 
#Process Software has a product that my old boss looked at.
#The contact was Joe DelRossi  delrossi@process.com
#(800)722-7770
# 

There are many TCP/IP for VMS products.  Probably the best in the market
is TGV MultiNet.  They also have an Australian distribution point (you
could ask simon@internode.com.au who that is).  Their address in the USA
is sales@tgv.com, 1-800-TGV-3440.

TGV Is the only *complete* package which supports NFS Client and Server,
RMT Client and Server, as well as a host of other products in a 100%
reliable configuration.

Their software also emulates the interface to the Wollongong and DEC UCX
products, so software can be run without changes.

Disclaimer: I don't work for TGV but I love their product and use it myself!

Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
With YOU, I can be MYSELF..  We don't NEED Dan Rather..
Newsgroups: comp.protocols.tcp-ip
From: fredg@ariel.yorku.ca (Fredrick Gonsalves)
Subject: Internet Address to Marquette University
Originator: fredg@t01.ariel.yorku.ca
Organization: York University, Toronto, Canada
Distribution: york
Date: Fri, 9 Oct 1992 17:55:12 GMT



Does anybody know the internet address for Marquette University ??

Newsgroups: comp.protocols.tcp-ip
From: weber@world.std.com (Bob Weber)
Subject: Netbios Encapsulation
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 15 Oct 1992 00:07:31 GMT

i believe there is one or more RFCs dealing with Netbios 
encapuslation within TCP packets.
can someone please tell me which they are?

does anyone have any experience with netbios 
encapuslation across an enterprise (WAN) internet? if
so, what are the problems, if any.  How does 
encapsulation affect problem resolution, if at all.
thanks.   
Bob Weber
 

-- 
------------------------------------------------------------------------
Robert Weber                       Voice: 617/570-0791 
Northeast Consulting Resources     Fax:   617/523-0150 
85 Devonshire Street, 4th floor   
Newsgroups: comp.protocols.tcp-ip
From: koziol@void.ncsa.uiuc.edu (Quincey Koziol)
Subject: TCP/IP implementation help?
Organization: Nat'l Center for Supercomputing Applications
Date: Thu, 8 Oct 1992 06:22:01 GMT

I've recently been modifying the TCP/IP kernel for NCSA Telnet for the
PC to be a happier and healthier member of the Internet host community
and I've come across an interesting problem.  First, some background:
The TCP/IP kernel is not interupt driven, i.e. the application using
the kernel must periodicly call a function which polls the network for
received packets and does the protocol interpretation of them.  The
other piece of background is that the routine which empties the TCP
buffer onto the network does not call the routine which polls the
network for incoming packet at any time while it is emptying the
TCP buffers.
	What tends to happen, is that everything will work fine for quite
a while and then a packet that we've sent out will get dropped (unbeknownest
to the sending host).  The rest of the buffer will finish being emptied out
onto the network, then the sending host waits for an ack of the data.
Because a packet has been dropped, this never comes, and eventually the
TCP port times out and begins resending the data.  All this works fine,
but somewhere through the resend of the outgoing data, an ack usually
comes through for the entire set of data which has been previously sent
(i.e. the dropped packet plus the entire bufferful which was initially
sent after the dropped packet).
	What I'd like to do is have that incoming ack update the information
in the outgoing port so that the rest of the buffer (which the receiving
host already has and has ack'ed) is not re-sent.  I'm unwilling,
however, to introduce a poll for received packets in the middle
of this tight loop pushing packets onto the net as fast as it can.  I was
wondering (if anyone has actually understood this so far... :-)
if anyone has a good algorithm for helping re-sends of TCP data act
a little more intelligent?

	Thanks,
		Quincey Koziol
		NCSA

koziol@ncsa.uiuc.edu
From: inpractutor@qut.edu.au
Newsgroups: comp.protocols.tcp-ip
Subject: Retrieving network information
Date: 8 Oct 92 15:10:43 EST
Organization: Queensland University of Technology

Hi friends,
I am now writing programs for my project assignment in tcp/ip. I am using
HP-UX and 386 BSD. I need to read the network information, such as IP address,
netmask, ARP table, network srtatistic (packets sent and received), etc.
I have tried to copy the small program from the Ultric manual ( because I do not
have HP-UX manual for that) but it didd not work. As I know that I should use
ioctl command. For those who knows to solve this problem, would you please help
me ? Thank you for your help.

Andrey Andoko

E-mail : andrey@sleet.fit.qut.edu.au
Newsgroups: comp.protocols.tcp-ip
From: ronf@panther3.panther.mot.com (Ron Feigen)
Subject: closing/re-using TCP sockets
Organization: Motorola Panther Project, Chandler, AZ
Date: Fri, 16 Oct 1992 22:35:26 GMT


A month or so back some folks posted the solution to enable immediate
reuse of TCP sockets (instead of having to wait for upto 2 minutes).
I thought it was TCP_LINGER, however this does not seem (per the man page)
to be the sockopt I am looking for.  Could somebody please repost the info.

Thanks in advance!


-- 

>
Ron Feigen
ronf@panther.mot.com
Newsgroups: comp.protocols.tcp-ip
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: what does completion of write() really mean?
Keywords: TCP Nagle
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 14 Oct 1992 02:22:38 GMT

In article <1992Oct14.004312.22804@novell.com>, donp@novell.com (don provan) writes:
> In article <qnblp1k@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >Never mind that combining the write()'s is the obvious thing to do.
> >The X guys say they have good reasons.
> 
> Tell the X guys that their reasons, whatever they are, aren't good
> enough to justify doubling the number of packets sent and, hence,
> doubling the impact their application has on the network
> infrastructure.  Blaming the poor performance of this transmission
> "technique" on TCP is something like using low octane gas in a race
> car, and then blaming the poor performance on the engine.
> 
> 						don provan
> 						donp@novell.com


No, you tell the X guys.
They are too many thousand of them for a coward like me.
Telling the X guys how badly they understand TCP/IP is as profitless
as pointing out the glaring network related holes and mistakes in that
netware stuff.

(I was talking about X, the window system, protocol, whatever.
  (They make some picayune distinctions among window manager, window
   system, and other stuff that if you get wrong, they won't talk to you.))


Vernon Schryver,  vjs@sgi.com
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SMTP Confusion
Date: 13 Oct 1992 20:03:09 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <0096207E.D04131A0@vms.csd.mu.edu> 5714krishnan@vms.csd.mu.edu writes:
>I am thinking of implementing SMTP (RFC 821).. 
>I have a very basic problem that being, how does a sender
>get a reply for
>(a) HELO
>(b) MAIL FROM: <sender>
>I guess, one needs to have a connection established (socket)
>before one starts getting back reply codes.

Yes.  In order to send a message, you connect to port 25 of the destination
system.

>For this connection one needs to know who he/she wants
>to mail to, (the address for) which does not come up until
>RCPT TO: <user@domain>
>I am possibly missing something very evident/obvious somewhere.
>I have gone thru the RFC a number of times and the example of
>a SMTP session that is given in the RFC just shows reply codes
>of the kind
>S: HELO
>R: 250 OK
>Where does the "250 OK" originate from and how does it communicate ?

The assumption is that the sending software "knows" which system it wishes
to communicate with.  Usually the API between the user application and the
mail transfer software provides a way to specify the destination.  In other
systems, the mail transfer software looks in the mail header for the "To",
"Cc", and "Bcc" headers and extracts destinations from there.  You should
also see the Domain Name System RFC's for information about looking up MX
records to find out the appropriate system to deliver mail to for a
particular address.

The RFC's only concern themselves with communication between systems, not
the interfaces between mail software on the sending or receiving systems.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.protocols.tcp-ip:4724 comp.unix.wizards:4288
From: dbox@net4.ics.uci.edu (Don Box)
Subject: XTI References
Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards
Reply-To: dbox@ics.uci.edu (Don Box)
Organization: UC Irvine
Date: 13 Oct 92 00:30:14 GMT

I'm looking for references on XTI.  Can someone tell me via email
where to find them (hopefully in electronic form).

Thanks in advance,
DB
From: heading@breeze.rsre.mod.uk (Anthony J.R. Heading)
Newsgroups: comp.protocols.tcp-ip
Subject: Cheap routers: moving on
Date: 16 Oct 92 11:40:57 GMT
Reply-To: heading%hermes.mod.uk@relay.mod.uk
Organization: Defence Research Agency

Thanks for the responses to my query about cheap routing. There
seemed to be a general feeling that none of the cheap-and-cheerful
methods were altogether satisfactory, so maybe buying a router
is the best way of doing things...

It transpires though, here in the sunny old UK, that packet-switched
X.25 connections are expensive. British Telecom seem fond of circuit
switching, and thus the best value comms option seems to be a
"Kilostream" line - which I understand to be a 64K synchronous link
which terminates with an X.21 port.

Does that change anybody's mind? If I wanted to connect that to a
Sun (for example), is it worth using a router to gate X.21 onto
an ethernet and then put an ethernet card in the "firewall" workstation,
or perhaps a SCSI X.21 port...

Any opinions gratefully received - peripheral facts as well. And if
I've completely got the wrong end of the stick I'd like to know
that too...

Anthony

------------------------------------------------------------
Defence Research Agency, St. Andrews Road, Malvern, Worcs, UK.
heading@hermes.mod.uk            Work: +44 684 896066
heading@ccint1.rsre.mod.uk       Home: +44 684 563596
-- 
Anthony Heading  (heading@hermes.mod.uk)
DRA Malvern, UK
Any opinions expressed are my own and in no way
represent those of my employer or any other organization.
Newsgroups: comp.protocols.tcp-ip
From: erick@sunee.uwaterloo.ca (Erick Engelke)
Subject: Re: what does completion of write() really mean?
Keywords: TCP Nagle
Organization: University of Waterloo
Date: Wed, 14 Oct 1992 19:46:46 GMT

 donp@novell.com (don provan) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>Never mind that combining the write()'s is the obvious thing to do.
>>The X guys say they have good reasons.
>
>Tell the X guys that their reasons, whatever they are, aren't good
>enough to justify doubling the number of packets sent and, hence,
>doubling the impact their application has on the network
>infrastructure.  Blaming the poor performance of this transmission
>"technique" on TCP is something like using low octane gas in a race
>car, and then blaming the poor performance on the engine.
>

The problem is due to the use of a reliable protocol (tcp) to
send real-time, unimportant data, particularly mouse updates.
UDP would have been a better network choice, but would have
severely changed the transport independant design of X.
Had udp been used for mouse i/o, the rest of the X data could 
be sent comfortably over Nagled tcp and we would all breath 
easier.  But would you want to start recoding X?  Yuck!

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke				 	            WATTCP Architect
erick@development.uwaterloo.ca     TCP/IP was easy but i still can't work VI
Newsgroups: comp.protocols.tcp-ip
From: ken@cujo.curtin.edu.au (Ken Taylor)
Subject: Re: SMTP Confusion
Organization: Curtin University of Technology
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 14 Oct 1992 06:17:28 GMT

5714krishnan@vms.csd.mu.edu wrote:
: I am thinking of implementing SMTP (RFC 821).. 
: I have a very basic problem that being, how does a sender
: get a reply for
: (a) HELO
: (b) MAIL FROM: <sender>
: I guess, one needs to have a connection established (socket)
: before one starts getting back reply codes.

Yes.. The most common form of this transport is to open a TCP connection
with port 25 of a local SMTP host...
(See appendix A of the RFC)

Usually, when you open the connection, the host will respond with a "welcome"
message, you then say "HELO your.machine.name"..

The host will then say "250..followed by something else irrelevant"

: For this connection one needs to know who he/she wants
: to mail to, (the address for) which does not come up until
: RCPT TO: <user@domain>

Why?

You should be able to send the mail to just about any SMTP host and it will
then take care of the forwarding of the message to the correct final
destination...

: I am possibly missing something very evident/obvious somewhere.
: I have gone thru the RFC a number of times and the example of
: a SMTP session that is given in the RFC just shows reply codes
: of the kind
: S: HELO
: R: 250 OK
: Where does the "250 OK" originate from and how does it communicate ?
: 
: Can anyone help me out or let me know where to look for help
: Replies would be most appreciated

Feel free to mail me if you need advice..  I have written a SMTP mailer
for the Macintosh and hence, been there before..

Ken
-- 
 Ken Taylor              |  "I have a friend who's seen inside my tiny brain
 ken@cujo.curtin.edu.au  |   He's seen the aging and the mildew from the rain
 Curtin University       |   And he does what he can to keep on top of every
 Perth, W. Australia     |     one of them"     - Happy Rhodes
Newsgroups: comp.protocols.tcp-ip
From: koziol@void.ncsa.uiuc.edu (Quincey Koziol)
Subject: Re: pc-tcp s/w 
Organization: Nat'l Center for Supercomputing Applications
Date: Thu, 8 Oct 1992 06:06:19 GMT

In article <1992Oct6.101423.9757@fallst> tkevans@fallst (Tim Evans) writes:
>radha@yrloc.ipsa.reuter.COM (radha) writes:
>
>
>>is there any public domain s/w equvalent to pc-tcp?
>
>CUTCP/CUTE is available via ftp from sun.soe.clarkson.edu and
>NCSA Telnet from zaphod.uiuc.edu.
                  ^^^^^^^^^^^^^^^
Close, but this should actually be: ftp.ncsa.uiuc.edu (also answers to
zaphod.ncsa.uiuc.edu) and the software is in the /PC/Telnet directory.
There is also equivalent Telnet software for the Macintosh in the
/Mac/Telnet directory.

	Quincey Koziol
	NCSA

koziol@ncsa.uiuc.edu



Xref: sparky comp.protocols.tcp-ip:4703 comp.benchmarks:1510
From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian)
Newsgroups: comp.protocols.tcp-ip,comp.benchmarks
Subject: Re: TCP/IP Benchmarks
Date: 9 Oct 92 22:31:23 GMT
Followup-To: comp.protocols.tcp-ip
Organization: Lawrence Livermore National Laboratory

In article <qdtg0po@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>The primary source for ttcp is brl.mil.  BRL evidently does not
>consider it a benchmark, but a file transfer protocol.  That's
>why they insisted on keeping the crazy -s default.

I think Mr. Schryver probably means ftp.brl.mil (128.63.16.158).  You can find 
ttcp.c under /pub on that machine.

mb
-- 
Mark Boolootian		booloo@llnl.gov		+1 510 423 1948
Newsgroups: comp.protocols.tcp-ip