Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2103 > unrolled thread

Re: Suggestion for UII Server Program Documentation

Back to article view | Back to comp.sys.apple2.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Suggestion for UII Server Program Documentation D Finnigan <dog_cow@macgui.com> - 2016-01-11 19:26 +0000
    Re: Suggestion for UII Server Program Documentation ultramagnus_tcv <mikew@thecomputervalet.com> - 2016-01-11 17:32 -0600
      Re: Suggestion for UII Server Program Documentation D Finnigan <dog_cow@macgui.com> - 2016-01-12 19:00 +0000

#2103 — Re: Suggestion for UII Server Program Documentation

ultramagnus_tcv wrote:
> On 2016-01-09 21:52:19 +0000, D Finnigan said:
> 
>> Mac OS X is multi-homed and retains its link-local address even after it
>> has
>> obtained an address through DHCP or other means. Its behavior follows the
>> RFC which is when communicating with a host using a link-local
>> destination
>> address, it will also use a link-local source address.
> 
> I hear you. I did not know that Mac OS X retained its link-local after 
> being handed an IP (or manually setting one). The same is true of 
> Windows? Of *nix?

Mac OS X's networking code is BSD-derived, that's all I know, so the BSD
systems may well keep their LL address. I don't know anything more beyond
that. I think the RFC talks about other implementations in major operating
systems, but I don't remember much about that part.

I did look into what was going on with the LL versus private-range 192.168.
address. When getting the SYN from Mac OS X, the W5100 was happily sending
out an ARP for 192.168.2.1, the Mac OS X machine sent its ARP reply, and the
W5100 was a happy camper. Completely unconcerned that it "wasn't supposed
to" communicate with its non-routable source address. That TCPDEMO program
also doesn't configure a subnet mask or a router, so that may have something
to do with the W5100's being so free. :-)


>> Yes. I'm going to write a 2-way chat program next. Also on the to do list
>> is
>> a DHCP client, and a wget program that will use ProDOS to save a file
>> downloaded via HTTP to disk.
> 
> Is that all? Then an IRC client? Multiplayer Choplifter? Minecraft client?
> 
> But seriously, the WGET utility sounds absolutely useful.

Everything that people wanted to do 10 years ago (for example, the 8-bit
graphical web browser) but couldn't because a *big* part of the equation was
either interfacing with an existing TCP/IP solution or writing your own-- is
now more possible today than it was back then, because the new Uthernet II's
built-in stack makes it *ridiculously easy* to program networking
applications, as long as you have your program logic settled. And the memory
footprint for TCP/IP is now just the size of your send and receive buffers
and a couple hundred bytes to interface with the W5100!

The 2-way chat is working, but has two issues: one is because I'm not
familiar with programming the 80-columns screen, so that should be an easy
fix for someone. And the other is really weird, and lies somewhere between
the W5100 interface code and the W5100 itself. But let's just say I managed
to get DOS'd with 8 MB per second of ACKs from the W5100, that came out to
be about 14,000 packets per second, when I opened a listening connection on
the Apple and connected to it with my Mac OS X system. Really odd.

But when you just connect from the Apple to a listening socket on the Mac,
everything is fine. You can 2-way chat all around (just that 80-columns
weirdness, that should be easy for someone to fix).

The source code for this is online *NOW*, it's on the Marina IP source disk
which I just released today for the January 2016 edition of Marina. Go to
the Marina site and scroll down to download the source disk. The file is
called U2TCPCHAT.

Everyone, please try this. It's cool (except for the DOS part). It's
configured to use 192.168.2.5 for the Apple II and connects to 192.168.2.1.
The port number is 20000.

What I do is on Mac OS X I use netcat nc -l 20000 and the Mac's IP address
is 192.168.2.1. Then on the Apple I use C to C)ONNECT to the Mac.

It sends the nickname over to the other person using the following prefix:
Esc, capital N, then the name. So to send your nickname over to the Apple,
once connected, hit Esc, type capital N, then your nickname, then press
return. That sends your name to the Apple. The Apple remembers what your
name is, and is listening all the time for a name. So once it gets your
name, it will remember it and will print it with whatever chat text you
type.

Of course if you've got the program running on two Apples connected to each
other, you don't have to do this. I haven't tested it this way yet, but
that's how it's supposed to work.

You can change these numbers of course but you need to reassemble with
Merlin Pro or patch the binary.

When I get this stuff cleaned up it will go on its own Uthernet II demo
programs disk that I will upload to Asimov. There are 2 or 3 other sample
programs also on the Marina source disk, including the TCP demo that's in
the manual.


> 
>> No matter what, the TCP sample program currently in the manual is going
>> to
>> change, because I have discovered some new techniques for transferring
>> data
>> to/from the W5100. Also because of the IP address problem that you
>> mention.
> 
> Yep. I saw the message in csa2programmer. Great news about the buffer 
> wraparound.

Yeah, that was a real relief to discover that behavior. But it turns out I
was playing against a stacked deck and there were some hardware issues in
the mix too that were frustrating my debugging efforts (were getting
*really* frustrated, to put it mildly).

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[toc] | [next] | [standalone]

#2105

On 2016-01-11 19:26:25 +0000, D Finnigan said:

> I did look into what was going on with the LL versus private-range 192.168.
> address. When getting the SYN from Mac OS X, the W5100 was happily sending
> out an ARP for 192.168.2.1, the Mac OS X machine sent its ARP reply, and the
> W5100 was a happy camper. Completely unconcerned that it "wasn't supposed
> to" communicate with its non-routable source address. That TCPDEMO program
> also doesn't configure a subnet mask or a router, so that may have something
> to do with the W5100's being so free. :-)

Oh no! Ha ha! Maybe there's a default gateway and mask of 0.0.0.0. That 
would be entertaining. Wireshark should expose this information to give 
you the truth of the matter if you're curious. :-) I suppose I could do 
it too.

> The 2-way chat is working, but has two issues: one is because I'm not

[SNIP]

> The source code for this is online *NOW*, it's on the Marina IP source disk
> which I just released today for the January 2016 edition of Marina. Go to
> the Marina site and scroll down to download the source disk. The file is
> called U2TCPCHAT.

Excellent! I'll give this a shot this afternoon. I might patch the 
binary to better fit my network. On the other hand, I may just leave it 
all as-is and see if netcat running on my Mac isn't just magically 
found somehow. Either way, I'll try it out.

> When I get this stuff cleaned up it will go on its own Uthernet II demo
> programs disk that I will upload to Asimov. There are 2 or 3 other sample
> programs also on the Marina source disk, including the TCP demo that's in
> the manual.

Excellent. Thanks. Downloading now. :-)

> Yeah, that was a real relief to discover that behavior. But it turns out I
> was playing against a stacked deck and there were some hardware issues in
> the mix too that were frustrating my debugging efforts (were getting
> *really* frustrated, to put it mildly).

Oh poo. Sorry to hear that. Looking forward to hearing about what you 
found when you get it sorted out.

[toc] | [prev] | [next] | [standalone]

#2111

ultramagnus_tcv wrote:
> On 2016-01-11 19:26:25 +0000, D Finnigan said:
> 
>> Yeah, that was a real relief to discover that behavior. But it turns out
>> I
>> was playing against a stacked deck and there were some hardware issues in
>> the mix too that were frustrating my debugging efforts (were getting
>> *really* frustrated, to put it mildly).
> 
> Oh poo. Sorry to hear that. Looking forward to hearing about what you 
> found when you get it sorted out.
>

I'm talking to Glenn Jones about it now. It seems to be an intermittent
issue. Those are the best kind.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web