Thread View: comp.os.os2.programmer
2 messages
2 total messages
Started by John Bartas
Tue, 31 Jul 1990 21:04
OS/2 Network APIs
Author: John Bartas
Date: Tue, 31 Jul 1990 21:04
Date: Tue, 31 Jul 1990 21:04
90 lines
3955 bytes
3955 bytes
Doug Harvey writes:
>I've got several applications in mind that would work great if I could
>connect two OS/2 workstations across our Token Ring LAN.
>
>We are running OS/2 EE v1.2 on IBM PS/2 70's with 120MB and 10MB+ RAM.
>Also, our LAN software is IBM LAN Server v1.2.
>
>What I want to do:
>
>Be able to connect any two workstations together so they can "talk",
>whatever that might mean (up to the application).
>
>What I've tried:
>
>Experimented with named pipes, but it doesn't look like I can connect
>(from a requester) to a named pipe that resides on another requester.
>The named pipe has to be on a server.
>
>I think APPC would do the job, but APPC imposed quite a bit of overhead,
>both in terms of running it, and coding the application.
. . . . .
>Doug Harvey
>--
>Hewitt Associates
>100 Half Day Road
>Lincolnshire, IL 60069
>(708) 295-5000
Doug;
One quick solution to your problem would be to use comercial
TCP/IP packages. These are now available for OS/2 over token ring, and
I think most of them include the Sockets API. Sockets is a de-facto
standard for calling TCP/IP fuctions in UNIX systems and as such
supports peer to peer connections of the type you need.
You have touched on a basic flaw in the Lan Manager model of
Networking: the artificial division of clients (or as IBM likes to
call them "requestors") and servers. On most non-PC oriented
networks, (ie tcp/ip) every machine is logically a peer of every
other machine, so they each have the option of beening client or
server or both. There is no technical reason why two OS/2 requestors
couldn't communicate via named pipes. This restriction is imposed for
a variety of marketing reasons.
You may have seen rumors in PC trade rags that TCP/IP is slow
or hard to use. These rumors are (I think) perpetuated by big companies
who want to lock you into their proprietary protocols. A good TCP/IP
stack is about as fast and much more versatile than any of the "PC-only"
networks.
FTP Software Inc. (ph# 617-868-3878) is a reputable supplier
of TCP/IP products which has just released an OS/2 product. The
Wollongong Group (415 962-7100) has a product in Alpha test. I know
there are other vendors, but I don't have the phone numbers handy.
You don't mention a budget for your projects, so I suspect the prices
($575 for FTP's OS/2 product in single quantities, probably similar
for their competitors) may be a problem. But at least you can
threaten your IBM/Microsft salesperson with buying peer-to-peer APIs
from third parties; and maybe someday they will allow it in named
pipes.
One last thought: The july 8th issue of Network World had an
article on Token Ring software products which included a usefull table
describing features and price of many OS/2 products (I got the FTP
info there). The article started by asserting that 16Mb Token Ring
would be cost competitive with ethernet in less than a year (which I
would bet a LOT of money against) but once you get past that it
contains a lot of usefull information. I noticed several products
claiming peer to peer connectivity, so you may find other solutions
there.
Another last thought: The 3com 3+open Lan Manager provided a
NetBios API which supported peer to peer connections. Does your IBM
product include a NetBios API? An application written to this would
be very portable to other OS/2 platforms and you may already have all
the software you need.
Good Luck!
-JB-
-----------------------------------------------------------------------
John Bartas | This space for rent.
NetPort Software |
Re: OS/2 Network APIs
Author: Christian Motz
Date: Sun, 26 Aug 1990 10:51
Date: Sun, 26 Aug 1990 10:51
25 lines
1785 bytes
1785 bytes
>Doug Harvey writes: > >> [...] >> >>I think APPC would do the job, but APPC imposed quite a bit of overhead, >>both in terms of running it, and coding the application. APPC will indeed do the job -- I am not sure what you are referring to with the overhead. The only real "overhead" with APPC is that you have to have the Communications Manager up and running. Once this is the case, the remaining overhead is not really that big. Coding an APPC Transaction Program under OS/2 is not really that big a problem, since the API for it is rather easy to use, and with, let's say 700 lines or so of code you could write yourself an interface which basically is as easy to use as file I/O functions or sockets under UN*X for that matter. The advantage of using APPC is that you do not need yet another communications package to achieve the desired functionality. Besides, if you are using remote data services in a LAN, CM is up and running anyway, so you can just as well use it anyway. If anyone is interested, I can elaborate on the usage of APPC a bit. Just drop me a line at the above address and I will get back to you, mailers willing. -- Christian Motz root@dialog.stgt.sub.org
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads