| Announcing AFPBridge [message #342694] |
Fri, 28 April 2017 18:10  |
|
|
Originally posted by: Stephen Heumann
I've just released AFPBridge, a tool that allows an Apple IIgs to
connect to file servers using the Apple Filing Protocol (AFP) over
TCP/IP. It works by using the existing AppleShare FST, but redirecting
its network traffic over TCP/IP rather than AppleTalk.
With AFPBridge, anyone with a Marinetti-compatible network interface
(such as an Ethernet card) can connect to AFP file servers from a IIgs,
with no need to set up an AppleTalk network. This provides a very
convenient way to move files to and from the IIgs, just by copying them
in the Finder or accessinging them in any other IIgs program.
For more information and downloads, see:
https://sheumann.github.io/AFPBridge/
--
Stephen Heumann
|
|
|
|
|
|
| Re: Announcing AFPBridge [message #342865 is a reply to message #342694] |
Sat, 29 April 2017 10:15  |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Stephen,
You've done significant work here. Very nice.
May I ask a few questions?
1. Have you done any timings to compare the speed advantage of AFP over
TCP/IP vs AFP over AppleTalk/LocalTalk?
2. You mention that since AFPBridge relies on Marinetti that P8 programs
(even when booted into GS/OS) are not able to access the file server. Do
you ever foresee a workaround/solution for that issue?
3. AFPBridge requires that the Control Panel settings for Slot 7 (ROM1)
or Slot 1/2 (ROM3) be set for AppleTalk even though the physical ports
themselves will not be accessed. I suppose this is because the
AppleShare startup routines check for that and may use some of the
AppleTalk firmware. Is it possible for those components to be modified
so that that would no longer be the case?
Also, I very much enjoyed your discussion of AFP 2.0 / 2.2 / 3.0 and how
the byte used for the ProDOS Filetype was changed with 2.X and thus made
file typing on an Apple II problematic. I remember experiencing that
issue when I briefly experimented with Mac <-> IIGS file sharing under
OS X 10.3 (Panther). I do suspect, however, that since the ProDOS file
type is derived from the Mac 4-character file type that a byte must
somewhere be available for use, but would it would require a
modification on the IIGS software side.
I suppose it's mostly moot since Snow Leopard (OS X 10.6 - AFP 3.0) and
that Netatalk is the preferred server now. I have been waiting to see if
someone can get Netatalk to build and work under the new 'Windows
Subsystem for Linux/WSL' capabilities of Windows 10. So far, no one has
mentioned it.
Hugh Hood
On 4/28/2017 5:10 PM, Stephen Heumann wrote:
> I've just released AFPBridge, a tool that allows an Apple IIgs to
> connect to file servers using the Apple Filing Protocol (AFP) over
> TCP/IP. It works by using the existing AppleShare FST, but redirecting
> its network traffic over TCP/IP rather than AppleTalk.
>
> With AFPBridge, anyone with a Marinetti-compatible network interface
> (such as an Ethernet card) can connect to AFP file servers from a IIgs,
> with no need to set up an AppleTalk network. This provides a very
> convenient way to move files to and from the IIgs, just by copying them
> in the Finder or accessinging them in any other IIgs program.
>
> For more information and downloads, see:
>
> https://sheumann.github.io/AFPBridge/
>
|
|
|
|
| Re: Announcing AFPBridge [message #342868 is a reply to message #342865] |
Sat, 29 April 2017 14:38 |
|
|
Originally posted by: Stephen Heumann
On 2017-04-29 14:15:40 +0000, Hugh Hood said:
> Stephen,
>
> You've done significant work here. Very nice.
>
> May I ask a few questions?
>
> 1. Have you done any timings to compare the speed advantage of AFP over
> TCP/IP vs AFP over AppleTalk/LocalTalk?
Unfortunately, it's generally slower over TCP/IP than over AppleTalk.
In some tests I did on an 8 MHz GS with ethernet, I measured around 11
KB/s for reads and a bit faster for writes, compared to around 19 KB/s
over AppleTalk. This is with either an Uthernet II card or a LANceGS
(they generally perform similarly), and with options that should
maximize performance (large reads and writes enabled).
The performance over TCP/IP seems broadly in line with other file
transfer programs like FTP clients. It would be interesting to profile
the TCP/IP performance here and see if it could be optimized. I suspect
there would be some opportunities, but they might involve significant
changes to Marinetti.
> 2. You mention that since AFPBridge relies on Marinetti that P8
> programs (even when booted into GS/OS) are not able to access the file
> server. Do you ever foresee a workaround/solution for that issue?
This is basically just because Marinetti doesn't work in P8 mode. I
haven't deeply looked into the reasons for that, but I'd think it might
be possible to make it work, although you would probably still have to
boot into GS/OS initially to load it.
> 3. AFPBridge requires that the Control Panel settings for Slot 7 (ROM1)
> or Slot 1/2 (ROM3) be set for AppleTalk even though the physical ports
> themselves will not be accessed. I suppose this is because the
> AppleShare startup routines check for that and may use some of the
> AppleTalk firmware. Is it possible for those components to be modified
> so that that would no longer be the case?
Yes, this is because the AppleTalk/AppleShare software stack expects
this. I think it would be possible to modify those components to remove
the requirement, although I don't know how extensive the modifications
would have to be to. The fact that System 6.0.1 was designed to work
with the Apple ethernet card may make this easier, since that wouldn't
have used the AppleTalk slot firmware.
> Also, I very much enjoyed your discussion of AFP 2.0 / 2.2 / 3.0 and
> how the byte used for the ProDOS Filetype was changed with 2.X and thus
> made file typing on an Apple II problematic. I remember experiencing
> that issue when I briefly experimented with Mac <-> IIGS file sharing
> under OS X 10.3 (Panther). I do suspect, however, that since the ProDOS
> file type is derived from the Mac 4-character file type that a byte
> must somewhere be available for use, but would it would require a
> modification on the IIGS software side.
In terms of the AFP 2.x protocol, the ProDOS filetype/auxtype is
separate from the Mac type/creator code, although some servers may
implement this by encoding the former into the latter. The server in OS
X (and possibly others) don't implement the ProDOS filetype/auxtype
part of the protocol. It would be possible to modify the AppleShare FST
to work around this by accessing the Mac type/creator code and deriving
the ProDOS type from it like the HFS FST does.
--
Stephen Heumann
|
|
|
|
|
|
| Re: Announcing AFPBridge [message #342873 is a reply to message #342868] |
Sat, 29 April 2017 16:15 |
D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Stephen Heumann wrote:
>
> The performance over TCP/IP seems broadly in line with other file
> transfer programs like FTP clients. It would be interesting to profile
> the TCP/IP performance here and see if it could be optimized. I suspect
> there would be some opportunities, but they might involve significant
> changes to Marinetti.
The entire elimination of Marinetti is in order now that we have the
Uthernet II, the best-selling Ethernet board for Apple II, with its built-in
TCP/IP stack. The creation of a Marinetti drop-in replacement that uses the
Uthernet II's capability would be the next best development for Apple II in
2017.
--
]DF$
Apple II 40th Anniversary User's Guide:
http://macgui.com/newa2guide/
|
|
|
|
| Re: Announcing AFPBridge [message #342875 is a reply to message #342694] |
Sat, 29 April 2017 17:19 |
Steven Nelson
Messages: 91
Registered: January 2013
Karma: 0
|
Member |
|
|
On Friday, April 28, 2017 at 5:10:23 PM UTC-5, Stephen Heumann wrote:
> I've just released AFPBridge, a tool that allows an Apple IIgs to
> connect to file servers using the Apple Filing Protocol (AFP) over
> TCP/IP. It works by using the existing AppleShare FST, but redirecting
> its network traffic over TCP/IP rather than AppleTalk.
Please give an example URL for accessing A2SERVER on a raspberrypi. I can't manage to connect and I suspect my URL in AFP Mounter cdev is wrong.
afp://piuser:pipasswd@raspberrypi.local/??? What should ??? be? Do I need to specify port? Shouldn't the shared volumes be A2FILES and GSFILES? Help!
I'm using Uthernet II on Rom01 GS and am connected to network. That much seems to be working.
Thanks for the development effort. This sounds just like a tool I am wanting!
--Steve
|
|
|
|
| Re: Announcing AFPBridge [message #342876 is a reply to message #342875] |
Sat, 29 April 2017 17:37 |
|
|
Originally posted by: Stephen Heumann
On 2017-04-29 21:19:09 +0000, Steven Nelson said:
> Please give an example URL for accessing A2SERVER on a raspberrypi. I
> can't manage to connect and I suspect my URL in AFP Mounter cdev is
> wrong.
>
> afp://piuser:pipasswd@raspberrypi.local/??? What should ??? be? Do I
> need to specify port? Shouldn't the shared volumes be A2FILES and
> GSFILES? Help!
Try something like afp://piuser:pipasswd@1.2.3.4/A2FILES (with 1.2.3.4
replaced by the actual IP address of the Raspberry PI).
With the AFP Mounter CDev, you always need to specify the name of the
shared volume as part of the URL. With A2SERVER, this is normally
A2FILES or (in some versions) GSFILES.
If you actually have a DNS server that can provide a mapping for the
domain name raspberrypi.local, then you should be able to use that in
place of the IP address, but AFPBridge doesn't support the
Zeroconf-based scheme used by modern versions of OS X for finding named
machines on the local network.
You don't need to specify a port unless you're using something other
than the standard port 548.
--
Stephen Heumann
|
|
|
|
| Re: Announcing AFPBridge [message #342878 is a reply to message #342876] |
Sat, 29 April 2017 19:45 |
Steven Nelson
Messages: 91
Registered: January 2013
Karma: 0
|
Member |
|
|
On Saturday, April 29, 2017 at 4:37:23 PM UTC-5, Stephen Heumann wrote:
> On 2017-04-29 21:19:09 +0000, Steven Nelson said:
>> Please give an example URL for accessing A2SERVER on a raspberrypi. I
>> can't manage to connect and I suspect my URL in AFP Mounter cdev is
>> wrong.
>>
>> afp://piuser:pipasswd@raspberrypi.local/??? What should ??? be? Do I
>> need to specify port? Shouldn't the shared volumes be A2FILES and
>> GSFILES? Help!
>
> Try something like afp://piuser:pipasswd@1.2.3.4/A2FILES (with 1.2.3.4
> replaced by the actual IP address of the Raspberry PI).
>
> With the AFP Mounter CDev, you always need to specify the name of the
> shared volume as part of the URL. With A2SERVER, this is normally
> A2FILES or (in some versions) GSFILES.
>
> If you actually have a DNS server that can provide a mapping for the
> domain name raspberrypi.local, then you should be able to use that in
> place of the IP address, but AFPBridge doesn't support the
> Zeroconf-based scheme used by modern versions of OS X for finding named
> machines on the local network.
>
> You don't need to specify a port unless you're using something other
> than the standard port 548.
>
> --
> Stephen Heumann
Thanks! It worked as expected. It is slow, as you mentioned. I am glad it is working.
--Steve
|
|
|
|
| Re: Announcing AFPBridge [message #342883 is a reply to message #342873] |
Sun, 30 April 2017 04:26 |
Oliver Schmidt
Messages: 132
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi David,
> The entire elimination of Marinetti is in order now that we have the
> Uthernet II, the best-selling Ethernet board for Apple II, with its built-in
> TCP/IP stack.
- The Uthernet II TCP/IP stack is limited to 4 open sockets.
- Marinetti does things like DHCP and DNS beside pure TCP/IP.
Regards,
Oliver
|
|
|
|
| Re: Announcing AFPBridge [message #342894 is a reply to message #342883] |
Sun, 30 April 2017 15:14 |
D Finnigan
Messages: 1154
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Oliver Schmidt <ol.sc@web.de> wrote:
> Hi David,
>
>> The entire elimination of Marinetti is in order now that we have the
>> Uthernet II, the best-selling Ethernet board for Apple II, with its built-in
>> TCP/IP stack.
>
> - The Uthernet II TCP/IP stack is limited to 4 open sockets.
So what? How often are more needed on the GS?
>
> - Marinetti does things like DHCP and DNS beside pure TCP/IP.
>
So what? Those can be rewritten and done better. DHCP is a hack in
Marinetti anyway, so is ARP. Ask Joachim Lange.
|
|
|
|
| Re: Announcing AFPBridge [message #342907 is a reply to message #342883] |
Mon, 01 May 2017 02:58 |
spectrumdaddy
Messages: 191
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Oliver Schmidt <ol.sc@web.de> wrote:
> - Marinetti does things like DHCP and DNS beside pure TCP/IP.
Marinetti handles DNS itself, but does not handle DHCP. It is the
Urhernet and other Ethernet Link Layers that do that.
Cheers - Ewen
|
|
|
|
| Re: Announcing AFPBridge [message #342908 is a reply to message #342894] |
Mon, 01 May 2017 02:58 |
spectrumdaddy
Messages: 191
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
D Finnigan <dog_cow@macgui.com> wrote:
> So what? Those can be rewritten and done better. DHCP is a hack in
> Marinetti anyway, so is ARP. Ask Joachim Lange.
As the source code for the Uthernet Link Layers is in the Puiblic
Domain, are you volunteering to improve the DHCP handling for us?
Cheers - Ewen
|
|
|
|
| Re: Announcing AFPBridge [message #342927 is a reply to message #342907] |
Tue, 02 May 2017 05:56 |
Oliver Schmidt
Messages: 132
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi Ewen,
>> - Marinetti does things like DHCP and DNS beside pure TCP/IP.
>
> Marinetti handles DNS itself, but does not handle DHCP. It is the
> Urhernet and other Ethernet Link Layers that do that.
Thanks for the clarification :-)
Regards,
Oliver
|
|
|
|
| Re: Announcing AFPBridge [message #343396 is a reply to message #342868] |
Tue, 16 May 2017 19:49 |
|
|
Originally posted by: Stephen Heumann
On 2017-04-29 18:38:31 +0000, Stephen Heumann said:
> On 2017-04-29 14:15:40 +0000, Hugh Hood said:
>
>> 1. Have you done any timings to compare the speed advantage of AFP over
>> TCP/IP vs AFP over AppleTalk/LocalTalk?
>
> Unfortunately, it's generally slower over TCP/IP than over AppleTalk.
> In some tests I did on an 8 MHz GS with ethernet, I measured around 11
> KB/s for reads and a bit faster for writes, compared to around 19 KB/s
> over AppleTalk. This is with either an Uthernet II card or a LANceGS
> (they generally perform similarly), and with options that should
> maximize performance (large reads and writes enabled).
In further testing, I've found that there is debugging code in recent
versions of Marinetti (3.0b3 to 3.0b8) that can severely reduce TCP/IP
throughput, in some cases by as much as 4-6x. When using a version of
Marinetti without that debugging code, AFPBridge is much faster,
providing substantially higher speeds than AFP over LocalTalk
(especially on an accelerated IIgs). I measured the following speeds
using my ROM 3 GS, connecting to a local Netatalk server with large
reads and writes enabled:
At 8 MHz (ZipGSX):
With LANceGS: 55 KB/s read, 57 KB/s write
With Uthernet II: 42 KB/s read, 47 KB/s write
At 2.8 MHz:
With LANceGS: 22 KB/s read, 27 KB/s write
With Uthernet II: 20 KB/s read, 22 KB/s write
You can get these faster speeds by using Marinetti 3.0b1 (which doesn't
include the debugging code), although I don't recommend it for general
use since it's an older version with known bugs that have since been
fixed. There will hopefully be a new release of Marinetti without the
debugging code made available soon.
--
Stephen Heumann
|
|
|
|
| Re: Announcing AFPBridge [message #343400 is a reply to message #343396] |
Wed, 17 May 2017 00:16 |
Alex Lee
Messages: 220
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 2017-05-16 23:49:37 +0000, Stephen Heumann said:
> On 2017-04-29 18:38:31 +0000, Stephen Heumann said:
>
>> On 2017-04-29 14:15:40 +0000, Hugh Hood said:
>>
>>> 1. Have you done any timings to compare the speed advantage of AFP over
>>> TCP/IP vs AFP over AppleTalk/LocalTalk?
>>
>> Unfortunately, it's generally slower over TCP/IP than over AppleTalk.
>> In some tests I did on an 8 MHz GS with ethernet, I measured around 11
>> KB/s for reads and a bit faster for writes, compared to around 19 KB/s
>> over AppleTalk. This is with either an Uthernet II card or a LANceGS
>> (they generally perform similarly), and with options that should
>> maximize performance (large reads and writes enabled).
>
> In further testing, I've found that there is debugging code in recent
> versions of Marinetti (3.0b3 to 3.0b8) that can severely reduce TCP/IP
> throughput, in some cases by as much as 4-6x. When using a version of
> Marinetti without that debugging code, AFPBridge is much faster,
> providing substantially higher speeds than AFP over LocalTalk
> (especially on an accelerated IIgs). I measured the following speeds
> using my ROM 3 GS, connecting to a local Netatalk server with large
> reads and writes enabled:
>
> At 8 MHz (ZipGSX):
> With LANceGS: 55 KB/s read, 57 KB/s write
> With Uthernet II: 42 KB/s read, 47 KB/s write
>
> At 2.8 MHz:
> With LANceGS: 22 KB/s read, 27 KB/s write
> With Uthernet II: 20 KB/s read, 22 KB/s write
>
> You can get these faster speeds by using Marinetti 3.0b1 (which doesn't
> include the debugging code), although I don't recommend it for general
> use since it's an older version with known bugs that have since been
> fixed. There will hopefully be a new release of Marinetti without the
> debugging code made available soon.
Wow. That's awesome!
- Alex
|
|
|
|
| Re: Announcing AFPBridge [message #343410 is a reply to message #343396] |
Wed, 17 May 2017 23:54 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Stephen,
Very nice. Those numbers, particularly on an 8 MHz IIGS, represent a
significant improvement compared to LocalTalk, which I suppose has a
theoretical maximum of around 20 kB/second, but in practice on an Apple
II delivers a rate quite a bit less than that.
Those numbers are so good, in fact, I won't bug you again (yet) about
figuring out how to support P8. ;-)
BTW, what makes the LANceGS faster than the Uthernet II?
Hugh Hood
On 5/16/2017 6:49 PM, Stephen Heumann wrote:
>
> I measured the following speeds
> using my ROM 3 GS, connecting to a local Netatalk server with large
> reads and writes enabled:
>
> At 8 MHz (ZipGSX):
> With LANceGS: 55 KB/s read, 57 KB/s write
> With Uthernet II: 42 KB/s read, 47 KB/s write
>
> At 2.8 MHz:
> With LANceGS: 22 KB/s read, 27 KB/s write
> With Uthernet II: 20 KB/s read, 22 KB/s write
>
|
|
|
|
| Re: Announcing AFPBridge [message #343573 is a reply to message #343410] |
Sat, 20 May 2017 20:43 |
|
|
Originally posted by: Stephen Heumann
On 2017-05-18 03:54:01 +0000, Hugh Hood said:
> BTW, what makes the LANceGS faster than the Uthernet II?
I looked into this a bit, and I think it probably relates to how the
cards transfer data over the Apple II bus. Basically, it's possible to
transfer two bytes to or from the LANceGS using one instruction, but
the Uthernet II can only transfer one byte at a time. This means the
core read/write loops used for I/O need to run twice the number of
iterations for the Uthernet II compared to the LANceGS, and I think
that's probably the main source of the speed difference. (The original
Uthernet can also transfer two bytes at once, so I'd expect it to be
closer to the LANceGS, but I don't have one to test.)
That said, I think there's some room for optimizing those core I/O
loops in all the ethernet link layers. For one thing, some degree of
loop unrolling would probably be helpful; as far as I can tell, none of
the ethernet link layers do that at the moment. Such optimization might
well reduce the speed differences.
An implementation that used the Uthernet II's built-in TCP/IP stack
would also cut out a lot of processing on the Apple II side, which I
expect would make it significantly faster in spite of the
byte-at-a-time I/O. However, I think any such implementation for the
IIgs would be a good thing only if it supported the existing Marinetti
APIs; fragmenting networking software between incompatible TCP/IP
implementation would not be desirable.
--
Stephen Heumann
|
|
|
|
| Re: Announcing AFPBridge [message #343599 is a reply to message #343573] |
Mon, 22 May 2017 02:50 |
Oliver Schmidt
Messages: 132
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi Stephen,
> An implementation that used the Uthernet II's built-in TCP/IP stack
> would also cut out a lot of processing on the Apple II side, which I
> expect would make it significantly faster in spite of the
> byte-at-a-time I/O.
Especially as it would not only be a question of spending cycles on the
65816 _or_ the W5100 MCU but a question of _parallel_ processing. In TCP
mode the W5100 takes care of flow control (incl. sending ACKs) totally
independ from its "host" CPU. So the communication peer can learn about the
current state of the TCP flow control (and act on it) even before the 65816
has started to process the data.
> However, I think any such implementation for the
> IIgs would be a good thing only if it supported the existing Marinetti
> APIs; fragmenting networking software between incompatible TCP/IP
> implementation would not be desirable.
>
Well said !
Regards,
Oliver
|
|
|
|
| Re: Announcing AFPBridge [message #343614 is a reply to message #343573] |
Tue, 23 May 2017 05:45 |
spectrumdaddy
Messages: 191
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Stephen Heumann <stephen.heumann@gmail.com> wrote:
> That said, I think there's some room for optimizing those core I/O
> loops in all the ethernet link layers. For one thing, some degree of
> loop unrolling would probably be helpful; as far as I can tell, none of
> the ethernet link layers do that at the moment. Such optimization might
> well reduce the speed differences.
I agree, some optimisation of the Link Layers might well speed things
up, but suspect there are more elements to this than just the transfer
speed you saw in bytes to and from the Uthernet card.
The speed of the IIgs will be a factor, as is the problem that still
needs to be addressed, that Marinetti does not negotiate the TCP
Options, so most hosts will send back a default packet size of 512
bytes, instead of the 1500 bytes that the LL supports.
The LL will correctly send packets of 1500 bytes out, it is just the
return packets that are not always coming back at maximum size.
> An implementation that used the Uthernet II's built-in TCP/IP stack
> would also cut out a lot of processing on the Apple II side, which I
> expect would make it significantly faster in spite of the
> byte-at-a-time I/O. However, I think any such implementation for the
> IIgs would be a good thing only if it supported the existing Marinetti
> APIs; fragmenting networking software between incompatible TCP/IP
> implementation would not be desirable.
It might be tricky to support this from Marinetti, without a
considerable re-write of its routiness, as well as possibly partial
rewrites of all the exisiting Marinetti aware software.
New apps of course could bypass Marinetti altogether, and use the
onboard TCP/IP stack of the Uthernet 2 card, but then they would limit
themslves to just that card, instead of being compatible with any of the
LLs that Marinetti currently, or in the future, supports.
DNS services are not part of the TCP/IP stack of the Uthernet 2 card, so
a DNS lookup routine would have to be provided by any software that used
the stack directly.
Cheers - Ewen
|
|
|
|
| Re: Announcing AFPBridge [message #343624 is a reply to message #343614] |
Tue, 23 May 2017 23:25 |
|
|
Originally posted by: Stephen Heumann
On 2017-05-23 09:45:45 +0000, Ewen said:
> I agree, some optimisation of the Link Layers might well speed things
> up, but suspect there are more elements to this than just the transfer
> speed you saw in bytes to and from the Uthernet card.
>
> The speed of the IIgs will be a factor, as is the problem that still
> needs to be addressed, that Marinetti does not negotiate the TCP
> Options, so most hosts will send back a default packet size of 512
> bytes, instead of the 1500 bytes that the LL supports.
>
> The LL will correctly send packets of 1500 bytes out, it is just the
> return packets that are not always coming back at maximum size.
Yes, I agree that those things impact performance too. I mentioned the
issue of how many bytes are transferred at a time because it's a
difference between the LANceGS and the Uthernet II, and I think it may
well be responsible for the speed difference I saw between them when
using otherwise the same configuration. The other issues, including the
one with not sending TCP options, should AFAIK apply the same way to
all the ethernet cards.
Another Marinetti performance issue I'm aware of is that TCP read
operations that use a pointer or an existing handle for the destination
will actually read the data into a new handle first, and then copy it
again to the actual destination. That is obviously inefficient,
although I haven't measured how large the overhead is.
However, all of these things are less significant than removing the
PtrToPtr debugging code. As I mentioned, that can increase throughput
by as much as a factor of six in some cases! Hopefully there will be a
new release without it made available soon. (It's also possible to
disable that code in current versions with a small patch to the TCPIP
init. If anyone's interested in that, let me know.)
>> An implementation that used the Uthernet II's built-in TCP/IP stack
>> would also cut out a lot of processing on the Apple II side ...
>
> It might be tricky to support this from Marinetti, without a
> considerable re-write of its routiness, as well as possibly partial
> rewrites of all the exisiting Marinetti aware software.
>
> New apps of course could bypass Marinetti altogether, and use the
> onboard TCP/IP stack of the Uthernet 2 card, but then they would limit
> themslves to just that card, instead of being compatible with any of the
> LLs that Marinetti currently, or in the future, supports.
>
> DNS services are not part of the TCP/IP stack of the Uthernet 2 card, so
> a DNS lookup routine would have to be provided by any software that used
> the stack directly.
The idea would be to make a separate version of Tool054 and/or the
TCPIP init, which would support the same tool call interface as
Marinetti but with a different implementation. For the basic TCP/IP I/O
calls, it would just act as a wrapper that used the Uthernet II's
onboard TCP/IP stack to do the work. Other Marinetti functionality,
including DNS, would still need to implemented on the GS. In fact, the
Marinetti code for those portions could probably be used with fairly
minor changes.
--
Stephen Heumann
|
|
|
|
| Re: Announcing AFPBridge [message #343752 is a reply to message #343624] |
Thu, 25 May 2017 02:59 |
spectrumdaddy
Messages: 191
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Stephen Heumann <stephen.heumann@gmail.com> wrote:
> The idea would be to make a separate version of Tool054 and/or the
> TCPIP init, which would support the same tool call interface as
> Marinetti but with a different implementation. For the basic TCP/IP I/O
> calls, it would just act as a wrapper that used the Uthernet II's
> onboard TCP/IP stack to do the work. Other Marinetti functionality,
> including DNS, would still need to implemented on the GS. In fact, the
> Marinetti code for those portions could probably be used with fairly
> minor changes.
That of course would be the simplest solution, but would only work for
the one instance of the Uthernet 2 card.
Marinetti source is available, so if anyone wishes to do this, they are
free to do so...
Cheers - Ewen
|
|
|
|
| Re: Announcing AFPBridge [message #382404 is a reply to message #342694] |
Sun, 24 March 2019 19:26 |
Steven Nelson
Messages: 91
Registered: January 2013
Karma: 0
|
Member |
|
|
On Friday, April 28, 2017 at 5:10:23 PM UTC-5, Stephen Heumann wrote:
> I've just released AFPBridge, a tool that allows an Apple IIgs to
> connect to file servers using the Apple Filing Protocol (AFP) over
> TCP/IP. It works by using the existing AppleShare FST, but redirecting
> its network traffic over TCP/IP rather than AppleTalk.
>
> With AFPBridge, anyone with a Marinetti-compatible network interface
> (such as an Ethernet card) can connect to AFP file servers from a IIgs,
> with no need to set up an AppleTalk network. This provides a very
> convenient way to move files to and from the IIgs, just by copying them
> in the Finder or accessinging them in any other IIgs program.
>
> For more information and downloads, see:
>
> https://sheumann.github.io/AFPBridge/
>
> --
> Stephen Heumann
I am having an issue connecting to A2SERVER on raspberrypi. I can connect from my IIgs Rom01 using uthernetII card. Same command from Rom3 using uthernet (1) results in error $0706. Perhaps only 1 GS can connect at a time, but I doubt that.
Rom3 is system 6.0.1 from CFFA boot. Rom01 is system 6.0.4 from CFFA3000 boot. both machines have 4Meg memory cards. Any suggestions?
--Steven
|
|
|
|
| Re: Announcing AFPBridge [message #382406 is a reply to message #382404] |
Sun, 24 March 2019 22:58 |
|
|
Originally posted by: Stephen Heumann
On 2019-03-24 23:26:17 +0000, steven-nelson@uiowa.edu said:
> I am having an issue connecting to A2SERVER on raspberrypi. I can
> connect from my IIgs Rom01 using uthernetII card. Same command from
> Rom3 using uthernet (1) results in error $0706. Perhaps only 1 GS can
> connect at a time, but I doubt that.
>
> Rom3 is system 6.0.1 from CFFA boot. Rom01 is system 6.0.4 from
> CFFA3000 boot. both machines have 4Meg memory cards. Any suggestions?
Error $0706 is a "no response from server" error. It could be that
there really isn't a response from the server, or that there's some
kind of networking error preventing it from getting through. It's
possible this could be related to a known bug in Marinetti, but I'm not
sure. Here are some things to check to help understand the problem:
What version of Marinetti are you using? If it's not 3.0b9, try that.
(Also try the latest version of the relevant link layer.) Have you
checked if other programs using Marinetti work properly?
Does it consistently fail the same way if you try to connect several times?
Is there a delay for a while between when you try to connect and when
the error message appears, or does it appear quickly? Do network
activity lights indicate activity during that period?
--
Stephen Heumann
|
|
|
|
| Re: Announcing AFPBridge [message #382408 is a reply to message #342694] |
Sun, 24 March 2019 23:16 |
Steven Nelson
Messages: 91
Registered: January 2013
Karma: 0
|
Member |
|
|
On 2019-03-24 23:26:17 +0000, steven...@uiowa.edu said:
> I am having an issue connecting to A2SERVER on raspberrypi. I can
> connect from my IIgs Rom01 using uthernetII card. Same command from
> Rom3 using uthernet (1) results in error $0706. Perhaps only 1 GS can
> connect at a time, but I doubt that.
>
> Rom3 is system 6.0.1 from CFFA boot. Rom01 is system 6.0.4 from
> CFFA3000 boot. both machines have 4Meg memory cards. Any suggestions?
Error $0706 is a "no response from server" error. It could be that
there really isn't a response from the server, or that there's some
kind of networking error preventing it from getting through. It's
possible this could be related to a known bug in Marinetti, but I'm not
sure. Here are some things to check to help understand the problem:
What version of Marinetti are you using? If it's not 3.0b9, try that.
(Also try the latest version of the relevant link layer.) Have you
checked if other programs using Marinetti work properly?
Does it consistently fail the same way if you try to connect several times?
Is there a delay for a while between when you try to connect and when
the error message appears, or does it appear quickly? Do network
activity lights indicate activity during that period?
--
Stephen Heumann
Thanks for reply. The Rom3 with uthernet is using Marinetti 3.0b8, the good Rom01 with uthernetII is using 3.0b9. I haven't updated Rom3 link layer. It is failing consistently each time I try to connect. There is a several second delay before the errmsg appears. My GS isn't positioned to see network activity on the uthernet card. I assume that because Marinetti seems to connect from control panel that it is working. Perhaps not. I will try to see if Safe2 (ftp) works. Good suggestions to try. Thanks. Sneakernet between Rom01 and Rom3 is getting me by for now ;-)
--Steven
|
|
|
|
| Re: Announcing AFPBridge [message #382425 is a reply to message #382404] |
Mon, 25 March 2019 10:36 |
Steven Hirsch
Messages: 798
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 3/24/19 7:26 PM, steven-nelson@uiowa.edu wrote:
> On Friday, April 28, 2017 at 5:10:23 PM UTC-5, Stephen Heumann wrote:
>> I've just released AFPBridge, a tool that allows an Apple IIgs to connect
>> to file servers using the Apple Filing Protocol (AFP) over TCP/IP. It
>> works by using the existing AppleShare FST, but redirecting its network
>> traffic over TCP/IP rather than AppleTalk.
>>
>> With AFPBridge, anyone with a Marinetti-compatible network interface
>> (such as an Ethernet card) can connect to AFP file servers from a IIgs,
>> with no need to set up an AppleTalk network. This provides a very
>> convenient way to move files to and from the IIgs, just by copying them
>> in the Finder or accessinging them in any other IIgs program.
>>
>> For more information and downloads, see:
>>
>> https://sheumann.github.io/AFPBridge/
>>
>> -- Stephen Heumann
> I am having an issue connecting to A2SERVER on raspberrypi. I can connect
> from my IIgs Rom01 using uthernetII card. Same command from Rom3 using
> uthernet (1) results in error $0706. Perhaps only 1 GS can connect at a
> time, but I doubt that.
>
> Rom3 is system 6.0.1 from CFFA boot. Rom01 is system 6.0.4 from CFFA3000
> boot. both machines have 4Meg memory cards. Any suggestions?
I have wanted to try this for some time. Really good to see my work to add
Apple 2 support to Netatalk is still proving useful.
|
|
|
|
| Re: Announcing AFPBridge [message #382426 is a reply to message #382425] |
Mon, 25 March 2019 10:59 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
in article S-GdnZ-wW7EbegXBnZ2dnUU7-LudnZ2d@giganews.com, Steven Hirsch at
snhirsch@gmail.com wrote on 3/25/19 9:36 AM:
> I have wanted to try this for some time. Really good to see my work to add
> Apple 2 support to Netatalk is still proving useful.
>
>
Steve,
Are you aware of any attempts by the Netatalk boys to get it working under
the Windows Subsystem for Linux (WSL) of Windows 10?
I do Google searches on this combo periodically, but have come up dry.
Apparently, you can now run daemons and servers with WSL now, but since (for
Netatalk 2/Apple II) you have to build AppleTalk support into the Linux
kernel, I don't know whether it's possible.
I know that Ivan Drucker has run Netatalk 2 in a virtual machine, but it
would be nice to cut that out altogether.
Hugh Hood
|
|
|
|
| Re: Announcing AFPBridge [message #382435 is a reply to message #382426] |
Mon, 25 March 2019 12:26 |
Steven Hirsch
Messages: 798
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 3/25/19 10:59 AM, Hugh Hood wrote:
> in article S-GdnZ-wW7EbegXBnZ2dnUU7-LudnZ2d@giganews.com, Steven Hirsch at
> snhirsch@gmail.com wrote on 3/25/19 9:36 AM:
>
>> I have wanted to try this for some time. Really good to see my work to add
>> Apple 2 support to Netatalk is still proving useful.
>>
>>
>
> Steve,
>
> Are you aware of any attempts by the Netatalk boys to get it working under
> the Windows Subsystem for Linux (WSL) of Windows 10?
>
> I do Google searches on this combo periodically, but have come up dry.
>
> Apparently, you can now run daemons and servers with WSL now, but since (for
> Netatalk 2/Apple II) you have to build AppleTalk support into the Linux
> kernel, I don't know whether it's possible.
>
> I know that Ivan Drucker has run Netatalk 2 in a virtual machine, but it
> would be nice to cut that out altogether.
Hi, Hugh. It wouldn't be the "Netatalk boys" for the simple reason that A2
compatibility is intrinsic to a modified Netatalk 2.x and the official
maintainers regard that major level as obsolete.
I think the RPi "appliance" approach is quite an elegant (and cheap) solution.
Is that not practical for your environment?
|
|
|
|
| Re: Announcing AFPBridge [message #382436 is a reply to message #382426] |
Mon, 25 March 2019 15:15 |
|
|
Originally posted by: Stephen Heumann
On 2019-03-25 14:59:41 +0000, Hugh Hood said:
> Are you aware of any attempts by the Netatalk boys to get it working under
> the Windows Subsystem for Linux (WSL) of Windows 10?
>
> I do Google searches on this combo periodically, but have come up dry.
>
> Apparently, you can now run daemons and servers with WSL now, but since (for
> Netatalk 2/Apple II) you have to build AppleTalk support into the Linux
> kernel, I don't know whether it's possible.
I think Netatalk with AppleTalk networking (i.e. the traditional
version used with Apple IIs) almost certainly won't work under Windows,
because (as you mentioned) it requires kernel support, which isn't
present in modern versions of Windows.
It may be possible to run Netatalk in AFP-over-TCP mode (the only mode
supported by Netatalk 3.x, and also configurable in Netatalk 2.x), and
use that in conjunction with AFPBridge on a IIgs. I haven't tried that
under WSL, but if it supports typical daemons and servers then I think
it would likely work.
--
Stephen Heumann
|
|
|
|
| Re: Announcing AFPBridge [message #382441 is a reply to message #382436] |
Mon, 25 March 2019 15:56 |
Steven Hirsch
Messages: 798
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 3/25/19 3:15 PM, Stephen Heumann wrote:
> On 2019-03-25 14:59:41 +0000, Hugh Hood said:
>> Are you aware of any attempts by the Netatalk boys to get it working under
>> the Windows Subsystem for Linux (WSL) of Windows 10?
>>
>> I do Google searches on this combo periodically, but have come up dry.
>>
>> Apparently, you can now run daemons and servers with WSL now, but since (for
>> Netatalk 2/Apple II) you have to build AppleTalk support into the Linux
>> kernel, I don't know whether it's possible.
>
> I think Netatalk with AppleTalk networking (i.e. the traditional version used
> with Apple IIs) almost certainly won't work under Windows, because (as you
> mentioned) it requires kernel support, which isn't present in modern versions
> of Windows.
>
> It may be possible to run Netatalk in AFP-over-TCP mode (the only mode
> supported by Netatalk 3.x, and also configurable in Netatalk 2.x), and use
> that in conjunction with AFPBridge on a IIgs. I haven't tried that under WSL,
> but if it supports typical daemons and servers then I think it would likely work.
If you want 8-bit //e clients (Workstation card) support you definitely will
need 2.x with my "short name" AFP support enabled.
|
|
|
|
| Re: Announcing AFPBridge [message #382454 is a reply to message #382435] |
Mon, 25 March 2019 21:47 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 3/25/2019 11:26 AM, Steven Hirsch wrote:
>
> I think the RPi "appliance" approach is quite an elegant (and cheap) solution.
> Is that not practical for your environment?
>
Steve,
I'm sure that using a Pi would be practical.
I'm just interested in minimizing the number of components required.
So, *if* Windows 10 (with the WSL) had everything required to run
Netatalk 2.x, I wanted to give it a try.
I do see that Acronis Files Connect offers an AFP server solution for
Windows, but it appears to be strictly AFP over TCP/IP. So, 8-bit Apples
need not apply.
< https://www.acronis.com/en-us/mobility/mac-windows-compatibi lity/>
Hugh Hood
|
|
|
|
Members
Search
Help
Register
Login
Home
