RE: Messaging protocol (was: IIS to as/400 odbc)

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

I'm not trying to be the negative one here, just a catalyst. So, let me add
my kudos to Buck too. He did indeed do an excellent job of describing a
application level protocol. Bravo!

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Wednesday, August 15, 2001 2:02 PM
To: midrange-l@midrange.com
Subject: RE: Messaging protocol (was: IIS to as/400 odbc)


Buck, thanks for this!  This is indeed a VERY cogent contribution to the
discussion.  You've done a great job of outlining the basic concepts of an
"application level protocol" as opposed to a communication level protocol
such as TCP/IP or APPC.  You've also touched on the very important issue of
sniffing and encryption, which is Leif's main issue - unless encrypted, even
proprietary protocols are subject to hacking.

Excellent post.

> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Buck Calabro
> Sent: Wednesday, August 15, 2001 12:49 PM
> To: midrange-l@midrange.com
> Subject: Messaging protocol (was: IIS to as/400 odbc)
>
>
> >> I have looked into Scott Klements socket programming
> >> site is this what you are talking about?
> >> If so (and I have not looked at the whole thing) how
> >> would this be different than opening acces to ODBC?
> >
> >The difference is that you would have your own protocol,
> >so a hacker is less likely to be able to figure out how to
> >access your data.
>
> I'd like to chip in here for what it's worth.
> I doubt that Joe is suggesting the creation of what the communications
> people strictly call a protocol; i.e. not creating a private version of
> TCP/IP or APPC.  Rather, it sounds more like creating a private command
> language.  Here's where brighter minds than mine should start their
> critique.
>
> I have a similar situation where I'm creating an API for outside
> vendors to
> access my application.  I don't want to give them my database via
> ODBC/DRDA/SQL, because then I need to explain (in gory detail) all the
> relationships between all the files.  The application is created by Synon,
> so the business rules are "enforced" by program code; not the database.
>
> I'm having the Synon folks write me a handful of functions to
> retrieve from
> and to update the database.  Eventually, they'll be able to use these
> functions within the Synon application, but for now, they're only for my
> use.
>
> Now the hassle is how to how to enable an outside vendor easy access to
> these functions.  I settled on sockets.  I'm writing my own set
> of commands
> so to speak, that the vendor can use to "call" my new API functions, so a
> typical transaction might go like this:
>
> (client)GET NEXT ORDER
> (server)  order=1234567
> (client)GET ORDER 1234567
> (server)  name=Fred Bloggs
> (server)  address=123 Broadway
> (server)  total=555.00
> (server)  ok
> (client)UPDATE ORDER 1234567 STATUS=APPROVED
> (server)  ok
>
> You get the idea.  A hacker can connect to the socket port by
> scanning, but
> my socket server program won't respond because the hacker doesn't know any
> of the proper commands.  Now, I didn't create commands to foil
> hackers, and
> this isn't sniffer-proof, but it's a little better than giving open ODBC
> access, in that there isn't a command to list all the tables in
> the system,
> like "select * from systables".
>
> We're working on a challenge/response authentication system to help secure
> this even more, but using  an encrypted session would be better than that.
> Challenge/response goes something like this:
>
> (client)CONNECT
> (server)hash=73a5r0kl3pa5ffg6
> (client uses an encryption algorithm to create a passkey, using
> the hash as
> a seed)
> (server uses the same algorithm using the same hash)
> (client)pass=5hh9as85ghy
> (server)login accepted
>
> I hope I've made a contribution...
>
> Buck

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com