Hai all,

I working on a client/server application in EVC.

The client is one place and server is in another place.

I want to connect the client with server using TCP/IP.

How shall I specify the IP address of the server in the client side?

Where I should use the domain name or ??

Please me.... its urgent...

Looking forward for the reply.

Thanx in advance..

In article <1141717834.523474.44920@j33g2000cwa.googlegroups. com>,
Prince <princevictor.moses@gmail.com> wrote:
> I working on a client/server application in EVC.
> The client is one place and server is in another place.
> I want to connect the client with server using TCP/IP.
> How shall I specify the IP address of the server in the client side?
> Where I should use the domain name or ??

Using a domain name is a convenience, so that you do not need to
change the code if the server should need to change IP address.

I would use hardcoded IP addresses:

- on systems that made it difficult to resolve IP addresses
- for code that only had to survive for a short time, where the
extra effort of setting up a Domain Name System (DNS) was not
worth the effort
- for code that only had to survive a short time, where the cost ($$$)
of setting up a domain name was not worth it
- if network security policies made it impractical or impossible to use
DNS resolution
- on systems with very restricted resources where DNS would use
more resources than the convenience warranted


If you are asking what code you need to use in order to supply a
hostname instead of an IP address, then the answer depends upon
which operating system you are using. Typically, you would use
gethostbyname(), passing in a string that might be either the
text version of the name or the text version of the IP address.
gethostbyname() returns a pointer to a static structure, one
of the members of which is a list of IP addresses in binary
format, in "network order". If your OS needs you to provide
binary addresses in "host order" then use ntohl() on the address
in "network order" to convert to "host order".

On 2006-03-07, Walter Roberson <roberson@hushmail.com> wrote:
> In article <1141717834.523474.44920@j33g2000cwa.googlegroups. com>,
> Prince <princevictor.moses@gmail.com> wrote:
>> I working on a client/server application in EVC.
>> The client is one place and server is in another place.
>> I want to connect the client with server using TCP/IP.
>> How shall I specify the IP address of the server in the client side?
>> Where I should use the domain name or ??
>
> Using a domain name is a convenience, so that you do not need to
> change the code if the server should need to change IP address.
>
> I would use hard-coded IP addresses:
>
> - on systems that made it difficult to resolve IP addresses
> - for code that only had to survive for a short time, where the
> extra effort of setting up a Domain Name System (DNS) was not
> worth the effort

I'll respectfully disagree with the use of hard-coded IP address, as I've
faced this situation before at some firms I've worked with, and in some
cases it can wind up being a big mistake - here's a few reasons why, and
a few workarounds:

- Your application may not be of a large scope or scale now, nor may you
have plans for it to be placed into wide use, but it may become so across
time and be subject to server moves / changes as your infrastructure grows.
When it comes time to move servers or expand / change the network, you're
left with the task of manually changing configuration files, or asking
your network administrators to accommodate change through the use of NAT
or another technique, which just slows change and creates for more
complexity.

So how to get the ease of use of a hard-coded address?

- DNS can be a pain to deal with, so can local host files, and the lookup
can cost your application time when setting up the initial connection,
which, if it's a time-critical application, you may not want. Consider the
use of a local DNS cache on the host like pdnds (for Intel hosts only I
believe...), or a local instance of bind to cache DNS lookups.

- Thinking strategically forward, consider the use of a load-balancer in
the form of a commercial appliance, Open Source OS load-balancing, or even
load-balancing in a network router (Cisco IOS has these features on some
platforms), which could afford you the use of one well-known IP address
behind which you could place servers supporting your application. Moving
the application servers could then be as easy as swapping the load-balancer's
IP address. Of course, this does add another layer of complexity as well.

----
__| |_ __ / _| |_ ____ __
dmfh @ / _` | ' \| _| ' \ _ / _\ \ /
\__,_|_|_|_|_| |_||_| (_) \__/_\_\
----

In article <slrne12a29.l1l.dmfh@llanfaethlu.dmfh.cx>,
DMFH <dmfh@n0spam.dmfh.cx.spamn0t> wrote:
>On 2006-03-07, Walter Roberson <roberson@hushmail.com> wrote:

>I'll respectfully disagree with the use of hard-coded IP address, as I've

Sounds like I should give some examples.

>> I would use hard-coded IP addresses:

>> - on systems that made it difficult to resolve IP addresses

For example, if you are working with an operating system that
does not have hostname resolution already written, and does not
offer an API and compiler that would make porting resolution code
to be realistic within the available timeframe.

>> - for code that only had to survive for a short time, where the
>> extra effort of setting up a Domain Name System (DNS) was not
>> worth the effort

>- Your application may not be of a large scope or scale now, nor may you
>have plans for it to be placed into wide use, but it may become so across
>time and be subject to server moves / changes as your infrastructure grows.
>When it comes time to move servers or expand / change the network, you're
>left with the task of manually changing configuration files, or asking
>your network administrators to accommodate change through the use of NAT
>or another technique, which just slows change and creates for more
>complexity.

When you -are- the Systems or Network administrator, you often
end up writing a fair bit of "throw-away code", whose expected lifetime
is 5 minutes to half an hour. If you can get a one-time job done in a 5
line shell script using a hard-coded IP address, then it is unprofitable
to go to the trouble of writing or installing or configuring DNS
(e.g., for a system you are about to scrub the disk on.)


>So how to get the ease of use of a hard-coded address?

>- DNS can be a pain to deal with,

You presume that DNS is available

>so can local host files,

You presume that local host files are available

>and the lookup
>can cost your application time when setting up the initial connection,
>which, if it's a time-critical application, you may not want. Consider the
>use of a local DNS cache on the host like pdnds (for Intel hosts only I
>believe...), or a local instance of bind to cache DNS lookups.

You presume that bind, or bind source and a C compiler, are available
for that system, and that the system API is fairly close to unix,
and that one has time to do the installation. You presume that
someone will be available to maintain the DNS infrastructure.
You presume that the application has the luxary of doing DNS
lookups within its time or packet-count constraints.


>- Thinking strategically forward, consider the use of a load-balancer in
>the form of a commercial appliance, Open Source OS load-balancing, or even
>load-balancing in a network router (Cisco IOS has these features on some
>platforms), which could afford you the use of one well-known IP address
>behind which you could place servers supporting your application. Moving
>the application servers could then be as easy as swapping the load-balancer's
>IP address. Of course, this does add another layer of complexity as well.

You presume that the application servers are under your control
or within your sphere of influence. You presume that the protocol
involved is routable (e.g., not broadcast). You presume that funds
are available with which to purchase that kind of equipment. You
presume that space, electricity, and cooling are available to house
the equipment. You presume that you can get authorization to install
that kind of equipment -- e.g., the local security policy might
be "Only equipment which has been certified as B3 or EAP6 or higher",
or the local administrative policy might be "All programmable devices
*must* be Windows".


I am by no means saying that you should not use hostname resolution
where available and practical within the time and budget constraints:
what I am saying is that there are some situations where forcing
use of hostname resolution would not make sense.


Consider, for example, if you were programming a space probe, where
the launch costs are $30,000 per pound, and where radiation-hardened
electronics must be used. You've been allocated 64 Kb for your
science task. Are you going to use that space to implement DNS
and to expect the probe to do hostname resolution (with 22 hour
round trip times)... or are you going to be thinking about how
someone was able to slip a moon-finding program into less than 100
spare bytes and that, after all, a new address could always be
remotely programmed in the unlikely event that mission control
wanted to renumber the target host... ?