[HECnet] Minimal Requirements

Sun Apr 7 01:50:05 PDT 2019

On 2019-04-06 16:11, Brian Hechinger wrote:
> TCP tracks the state of the connection. When I server accepts a TCP 
> connection it takes note of the source address and port and sends 
> responses there.
> 
> UDP just blindly throws packets wherever you tell it to. It does not 
> track state and so it has no idea where to send the response. That's why 
> UDP based services need to be setup on both ends.

This is a slight bit simplified.
For TCP, when you create a socket listening for an incoming connection, 
you can either define the other end to be a wildcard, in which case it 
will accept a connection from anywhere, and record the actual remote end 
when the connection is established, just like you say, or you can define 
the remote end from the start, in which case the TCP socket will only 
accept a connection from that remote destination.
Or at least, this is how all TCP implementations I've seen works. I have 
not looked at the VMS implementation, so it might be that it is 
different. But all Unixes I've ever seen, as well as my implementation 
for RSX works that way.

For UDP, you can bind a socket to a specific remote destination or not. 
If you do not bind it, every transmit will have to also provide what 
destination to send the packet to, and at reception any received packet 
is acceptable. However, if you do bind the socket, you do not need to 
tell where to send each packet, since that will be given by the socket 
information instead, and at reception only packets from that specific 
remote host will be accepted and all others will be dropped. But, as you 
say, for UDP this binding is not automatic. But you don't need to set it 
up in the socket at all.

   Johnny

> 
> -brian
> 
> On Sat, Apr 6, 2019, 03:44 Keith Halewood <Keith.Halewood at pitbulluk.org 
> <mailto:Keith.Halewood at pitbulluk.org>> wrote:
> 
>     I know :)
> 
>     I think the 'other' endpoint address is only needed for UDP circuits.
> 
>     Keith
> 
>     -----Original Message-----
>     From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
>     [mailto:owner-hecnet at Update.UU.SE
>     <mailto:owner-hecnet at Update.UU.SE>] On Behalf Of Supratim Sanyal
>     Sent: 05 April 2019 23:28
>     To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE>
>     Subject: Re: [HECnet] Minimal Requirements
> 
>     You do realize that DUNE connected right back from your new IP
>     address with no intervention needed at least on IMPVAX, don't you?
>     Which would be encouraging news for Dave's original concern with
>     dynamic IPs.
> 
>     Supratim
> 
>      > On Apr 5, 2019, at 2:18 PM, Keith Halewood
>     <Keith.Halewood at pitbulluk.org <mailto:Keith.Halewood at pitbulluk.org>>
>     wrote:
>      >
>      > Hi,
>      >
>      > This is a partial repeat of another message addressed to individuals.
>      >
>      > Sorry I've been incommunicado. To cut a long story short, a car
>     crashed into our local exchange and completely demolished it. Our
>     internet routing failed over to 4G (dynamically allocated IP address
>     ironically) so our source IP addresses have changed. This should not
>     have affected email because we have failover there too. Due to a
>     slight misconfiguration, this didn't happen properly. I've only just
>     noticed with a whole load of messages bouncing back to me from our
>     email server.
>      >
>      > So, as a result, at least until end of Sunday, I won't be able to
>     accept incoming DECnet over TCP connections to our fixed addresses.
>     I notice that area 46 is connected via 31. PIVAX0 on 29.200 is
>     currently connectionless though.
>      >
>      > Incidentally, gmail doesn't seem to care about SPF configuration
>     (or is yet to see my updated value) and so is treating mail to it
>     from me via a backup route as spam and blocking it. This may fix
>     itself shortly.
>      >
>      > Keith
>      >
>      > -----Original Message-----
>      > From: owner-hecnet at Update.UU.SE
>     <mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE
>     <mailto:owner-hecnet at Update.UU.SE>] On Behalf Of Johnny Billquist
>      > Sent: 04 April 2019 23:32
>      > To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE>
>      > Subject: Re: [HECnet] Minimal Requirements
>      >
>      >> On 2019-04-04 15:28, Paul Koning wrote:
>      >>
>      >>
>      >>> On Apr 4, 2019, at 7:53 AM, Supratim Sanyal
>     <supratim at riseup.net <mailto:supratim at riseup.net>> wrote:
>      >>>
>      >>> On 4/4/19 6:12 AM, Keith Halewood wrote:
>      >>>> Hi,
>      >>>> I'm pretty sure that a TCP listen doesn't care who connects to
>     it on VAX Multinet. UDP is a different matter.
>      >>>> For example, there's a listener device set up with a 1.1.1.1
>     address on DUNE here. PIVAX0 connects to it from a completely
>     different address. I use access controls on the router to restrict
>     just who is allowed to connect to it.
>      >>>> If you want I can set up another incoming line/circuit and you
>     can connect to it. I'm in area 29 FYI.
>      >>>
>      >>> I have listeners waiting on 0.0.0.0. Yes, MULTINET does not
>     seem to care what address connections come in from.
>      >>
>      >> Does that mean anyone can connect to HECnet without any
>     authentication?  Or is DECnet node init authentication used?
>      >>
>      >> "Security by obscurity" only goes so far.  Is it good enough for
>     HECnet?
>      >
>      > So far that's mostly what we have, yes.
>      > I have from time to time considered maybe adding a password on
>     the link, as DECnet do support that.
>      >
>      > But so far, there has never been a single instance of someone
>     actually trying to connect some unknown node with DECnet on any link
>     of mine. But it is most likely just because pretty much any remote
>     script-kid just have no clue that DECnet even exists, what to do
>     with it, or anything else.
>      >
>      > Also, the worst I think anyone could do would just be disrupting
>     DECnet.
>      > But maybe someone else can think of anything else potentially
>     interesting someone could do by hijacking a circuit.
>      >
>      > My biggest issue with those link passwords in RSX is that I think
>     I can only have one password, and it will be applied to all links.
>     And I also think that maybe I had to turn it on on all links if I
>     turn it on on any.
>      >
>      > But if people are willing to experiment some, we could test
>     enabling it.
>      >
>      > For the bridge, though, it requires that both ends are known. No
>     wildcard connections allowed.
>      >
>      >   Johnny
>      >
>      > --
>      > Johnny Billquist                  || "I'm on a bus
>      >                                   ||  on a psychedelic trip
>      > email: bqt at softjar.se <mailto:bqt at softjar.se>             || 
>     Reading murder books
>      > pdp is alive!                     ||  tryin' to stay hip" - B. Idol
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol