Fog Creek Software
Discussion Board




N-Tier stuff

I'm considering starting a n-tier system and I was wondering about the underlying protocol. I was thinking of writing it on top of TCP/IP, so I can have clients written on any platform, running on a PDA, web browser, Windows GUI app etc. I was wondering, how does the low level stuff works? Will it be stupid if I implement it in a way that, say, the client sends something like  "I WANNA ADD A CLIENT TO THE DATABASE. *DATA FOLLOWS*" and the server replies with "HEY, EVERYTHING WORKED OUT FINE" or "NO CIGAR BECAUSE *^*%% IS NOT A VALID CLIENT NAME". Of course, it could just send a number and the client could lookup the error or something like that, but you get the idea. Since people are shelling out $5000 or whatever for stuff like Corba/Midas or whatever Delphi guys are calling it these days and thinking it's a life saver, I wonder if implementing something like this is a stupid idea for reasons I don't know. BTW, I'll probably write the middle ware in C#.

Any advices?

Popeye
Friday, June 11, 2004

Nothing wrong with that approach, except that you'll have to do exact string compares on very long strings to check incoming messages. Better use strings like "ADD0", "OKOK", or whatever (also saves bandwidth).
Actually, this is the approach taken by many protocols.
Good luck!

P.S. You don't sound like you've done your homework on this. Before starting, make sure that you read about other protocols to get up to speed. Remember that thing about standing on the shoulder(s) of (a) giant(s)?

Janonymous
Friday, June 11, 2004

Read up on Service Oriented Architecture and web services. Then you're using an existing HTTP architecture which includes protocols for nonreceipt, retransmission, etc.

Be advised that you need some careful design if you're going to use web services, since they do add overhead to your communications channels, which can really exacerbate the problems of "chatty" clients.

However, if you design your client this way then it's trivial to provide for clients outside the firewall (SSL, authentication, and you're done)

SOA and web services are NOT a panacea or a silver bullet, but they're a pretty good option to consider along with Remoting, sockets, messaging, etc.

Philo

Philo
Friday, June 11, 2004

Philo: TCP already has retransmission and stuff. UDP does not. Maybe you mean some more advanced things, but generally speaking, TCP sockets are simple and safe to use.

Janonymous
Friday, June 11, 2004

Janonymous - you're right, my mistake. :-)

However, having implemented both sockets-based and web service-based architectures, I'll never touch socket-based again if I don't have to.

Philo

Philo
Friday, June 11, 2004

You might want to look up .NET Remoting and .NET Enterprise Services or Web Services / WSE before you go reinventing the wheel.
If you are talking Internet app as in outside the firewall, just three words: HTTP port 80

Just me (Sir to you)
Friday, June 11, 2004

"TCP already has retransmission and stuff."

Only until timeout. For longer timescales you need to add on top.

Just me (Sir to you)
Friday, June 11, 2004

Yep, a warning might be in place for everyone who wants to do anything with sockets: RTFM.
Official documentation tends to be really spaghetti, but there are very good tutorials and examples out there.

But maybe you're right Philo, as I had to work with sockets back in university; I remember that I spent more time creating a client/server class structure than on the actual functionality of the program. It was UDP though. But of course university doesn't teach you how to use real-world products like pre-baked c/s products. :-(

Anyway, good luck popeye.

Janonymous
Friday, June 11, 2004

One quick suggestion.

Instead of passing data at the TCP/IP or UDP level, think about using a messaging service like IBM MQ Series (which is cross platform and multi-protocol) or the Microsoft equivalent for Windows only. Both provide the abstraction of a queue to which you post messages that other applications will read. The delivery of the messages and their ordering is guaranteed. All the hassle of failed connections, timeouts/ redelivery etc. are handled by the middleware. I seem to recall that IBM's product can also deliver multiple copies of the same message to different applications (for publish and subscribe like stuff).

MQ has a pretty lean API that I found straightforward to learn.

David Roper
Friday, June 11, 2004


You're working at a much too low level.

This is *why* WebServices (or Service Oriented Architectures, if you prefer) were created.  They are specifically designed to allow multiple clients on a variety of platforms to communicate and share data.

XML is *not* the answer to everything, but this is *exactly* what it was designed for.

KC
Friday, June 11, 2004

The hardest part of designing a protocol isn't the sockets or web services, it's the content of the messages.

Once you publish the protocol so that it gets used by code you don't have direct control over, you have a legacy system out there. When you want to change the protocol, the needs of existing clients have to be accounted for. So you need to think about versioning and backwards compatibility at the beginning and try to come up with a set of messages that will be flexible enough to cover some of your anticipated future extensions.

Beth
Friday, June 11, 2004

> Since people are shelling out $5000 or whatever for stuff like Corba/Midas or whatever Delphi guys are calling it these days and thinking it's a life saver, I wonder if implementing something like this is a stupid idea for reasons I don't know.

If you're using C# you can use .NET Remoting (for free) instead of Corba; or use Web services.

The reason why it's "stupid" include:

- You'll spend effort implementing the transport connection for example: what if it's not simple request/response (what if server wants to send unsolicited notification to the client? how do you get through firewalls? what do you need to do to add security/encryption?

- You won't interoperate with 3rd-party products, e.g. Web servers

- You may also spend effort serializing/deserializing C# structs

> Will it be stupid if I implement it in a way that, say, the client sends something like  "..." and the server replies

That's the way things are usually done; but I'd recommend using a higher level than TCP/IP (for example, using HTTP ... or DCOM ... or CORBA ... or .NET Remoting).

There are exceptions to this "rule" of using as 'high' a protocol level as possible (for example, VoIP data is transported using RTP/UDP) ... but, if you're asking, these exceptions probably don't apply to you.

Christopher Wells
Friday, June 11, 2004

If you're going to use the .NET remoting then be aware that there are some limitations/problems with .NET channels. I was recently recommended GenuineChannels (http://www.genuinechannels.com) which makes working through proxies easy-peasy and provides things like timeout on TCP. Works for me and good support

gwyn
Friday, June 11, 2004

> I was recently recommended GenuineChannels

Yes, and I see that as a recommendation in favour of writing to a high-level protocol (.NET remoting in this case): the fact that you can 'plug in' the use of a different channel implementation (i.e. a different network transport) without changing your application-specific code.

Christopher Wells
Friday, June 11, 2004

I'll repeat myself on this one:


You're working at a much too low level.

This is *why* WebServices (or Service Oriented Architectures, if you prefer) were created.  They are specifically designed to allow multiple clients on a variety of platforms to communicate and share data.

XML is *not* the answer to everything, but this is *exactly* what it was designed for.

KC
Friday, June 11, 2004

Thanks. WebServices sounds intriguing. Writing a thin client in PHP using .NET remoting wouldn't be too much fun, right? I`ll probably implement it as some kind of glorified text (XML) protocol on top of TCP/IP, or use some kind of WebServices infrastructure. I intend to open source this project, so the easier it is to write clients, the better.

Thanks for the great input so far.

Popeye
Friday, June 11, 2004

Check out RemObjects. This is what they do. Webservices, service orientated architecture,etc. Excellent products, excellent service. They make it easy to do all this kind of stuff.

jb
Monday, June 14, 2004

*  Recent Topics

*  Fog Creek Home