i have to develop a client server application in which server is runing over Linux and Client is runing over Windows. wht problems can i face for doing so?, is it possible to do so? or any material which can help me to achieve my objective.

thnx

It's most definitely possible. A perfect example is that many web servers run Apache in a Linux environment, and browsers running in Windows have no problem at all communicating with them.

You'll most likely want to learn how to program with sockets, and develop a well defined protocol that the two apps will agree on. As in my web server example. Both the server and client understand the HTTP protocol, and thus are able to communicate regardless of their underlying platform.

One thing to watch for is if you develop a protocol that sends and receives binary data, you must be aware of endianness. Endianness isn't OS specific, but more specific to the processor architecture. That is, an Intel chip uses a little endian format regardless of whether it runs Linux or Windows. But, you may be running Linux on an Alpha or Sparc or anything else that has the possibility to be big endian. Your protocol should ensure that if binary data is passed, it agrees on an endianness for how numeric values are passed.

What languages do you know?

What I would do is, not bother with C socket programming to start with.
Use something like perl or tcl/tk to prototype a quick application.

It's relatively easy to get some communication between two machines this way.
The hard bit is always getting your communication worked out!

You can concentrate on getting your design working
as it's much easier to code than if using C.

Then if you get the two halves talking, your top level design works.
if need be you can recode in C.


you won't have the
double problem of getting your socket programming right too!

just a thought

These requirements are old-hat in the computing world. You do not need to start from scratch. You do not need to start out by "hacking sockets." Instead of letting your thoughts jump ahead to "low-level" implementation details, keep your view "high-level" as long as possible.

Start by defining, in detail, what the application needs to do, and for whom. Not how, but what. Once you have done that, in a week or two, proceed to identify -- and research to some degree -- at least five ways that the job could be done, using five different tools. Choose the simplest; not the slickest.

It is also desirable to design so that "it doesn't matter which machine is driving the train." Development tools and techniques should be common to both. That can take some doing.

Remember also, your "prototype" will be your finished work, so delay creating prototypes as long as possible.

I think you'll find it very hard to design something for TCP streams
without playing with them first.

How can you define in detail if you have no experience of how
TCP streams operate?