On Monday, 03/10/2008 at 08:56 EDT, RPN01 <[EMAIL PROTECTED]> wrote:
> But, while I understand that, once a UDP message leaves my hands, there
is no
> guarantee of delivery, I would think that the RFC would kick in once the
> message had actually been sent. The fact that the failure was still
> But, while I understand that, once a UDP message leaves my hands,
there is no guarantee of > delivery, I would think that the RFC would
kick in once the message had actually been sent. > The fact that the
failure was still inside my box, and completely detectable, bothers me.
> Is it really righ
On Mon, Mar 10, 2008 at 2:55 PM, RPN01 <[EMAIL PROTECTED]> wrote:
> But, while I understand that, once a UDP message leaves my hands, there is
> no guarantee of delivery, I would think that the RFC would kick in once the
> message had actually been sent. The fact that the failure was still inside
I did find my problem, and as usual, it was of my own making I mis-read
the PIPE UDP help, and had specified 514 as the sending port, rather than
specifying 0 and allowing it to choose a port above 1024. I can fix this
But, while I understand that, once a UDP message leaves my hands, there
On Fri, Mar 7, 2008 at 9:44 PM, RPN01 <[EMAIL PROTECTED]> wrote:
> Also: If I violate this using Pipe and the UDP stage, why don't I get a
> non-zero return code? The UDP stage quietly accepts records, and the pipe
> returns a zero return code, but no data is actually sent. There's no errors
Mos
>> Also: If I violate this using Pipe and the UDP stage, why don¹t I get a
>> non-zero return code?
> Because there are no guarantees in the IP protocol specifications that UDP
> packets are ever delivered. UDP was designed to have those semantics, > and
> thus if you use UDP, you're expected
> My point exactly.
FTPSERVE is listed as an authorized virtual machine in the PORTS list in the
TCPIP PROFILE. This permits it to listen on a low port.
The FTP client does not use a low source port, so is not subject to the
restriction.
> My question now is what is the logic behind requiring a user to be in
> TCPIP¹s Obey list to allow it to use certain TCP/IP ports and protocols. It
> isn¹t everything, because things like FTP work, and I think you can play
> fairly fast and loose with higher numbered ports.
Port number < 1024 ar
To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Using UDP port 514 in z/VM TCPIP...
>
>
> But my port wasn't specified; I was trying to talk to port 514 on the
> destination. If what you're implying was true, then only OBEY users
> could use FTP, since it's port number is 21.
Behalf Of RPN01
Sent: Friday, March 07, 2008 3:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Using UDP port 514 in z/VM TCPIP...
But my port wasn't specified; I was trying to talk to port 514 on the
destination. If what you're implying was true, then only OBEY users
could use FTP, since
I'd buy that, except that it wasn't a protocol error; the problem was
entirely inside z/VM and TCPIP, in that a parameter was missing in the
PROFILE TCPIP, which isn't part of any of the standards. If I put my UDP
message out on the wire and it gets lost, I'll accept that. But if my own
interface r
But my port wasn¹t specified; I was trying to talk to port 514 on the
destination. If what you¹re implying was true, then only OBEY users could
use FTP, since it¹s port number is 21.
--
Robert P. Nix Mayo Foundation.~.
RO-OE-5-55 200 First Street SW/V\
507-284-084
That is part of the UDP design. If an error occurs the data is silently
discarded.
RPN01 wrote:
I was going to ask what I was doing wrong... But I figured that out just
a moment ago.
My question now is what is the logic behind requiring a user to be in
TCPIP’s Obey list to allow it to use ce
I am not an expert, but from what little I know, the "lower ports"
(<1024) were considered to be "privileged". The convention was that if
the originating port was <1024, then the remote end could __assume__
that the originator was "authorized" in some special way. And so, by
convention, the "lower
14 matches
Mail list logo
