Network Identification/Administratrtion/Flow Control/Error pattern in C

Hi

I have a project to connect several control boxes with a TCP based
network. The TCP/IP stacks is  available.

I would like to know if there are  some design patterns in "C", which
deal with the identification of other clients in a TCP Network( such as
broadcasting every several secondes), establishment of link and flow
control/Error control.  

Thanks in advance


Steven

Steven P wrote:
> Hi
> 
> I have a project to connect several control boxes with a TCP based
> network. The TCP/IP stacks is  available.
> 
> I would like to know if there are  some design patterns in "C", which
> deal with the identification of other clients in a TCP Network( such as
> broadcasting every several secondes), establishment of link and flow
> control/Error control.  
> 

Get a good book on TCP/IP programming.

For broadcasting, you'll need UDP (or ICMP or raw
Ethernet).

The TCP connections have already link establishment,
error retries and flow control built-in.

The detailed patterns depend on the interface to
your protocol stack (e.g. sockets).

-- 

Tauno Voipio
tauno voipio (at) iki fi

The question I ask is above TCP/UDP layer.

For example:

1. detect how many and which clients are on-line
2. how to deal with the connection drop in the communication.

Of course these are application specific, but I think there must be
already some patterns there.

Steven


> > I would like to know if there are  some design patterns in "C", which
> > deal with the identification of other clients in a TCP Network( such as
> > broadcasting every several secondes), establishment of link and flow
> > control/Error control.
> >
>
> Get a good book on TCP/IP programming.
>
> For broadcasting, you'll need UDP (or ICMP or raw
> Ethernet).
>
> The TCP connections have already link establishment,
> error retries and flow control built-in.
>
> The detailed patterns depend on the interface to
> your protocol stack (e.g. sockets).
> 
> -- 
> 
> Tauno Voipio
> tauno voipio (at) iki fi

On 7 Oct 2006 08:18:59 -0700, "Steven P" <photodose@gmx.de> wrote:

>The question I ask is above TCP/UDP layer.
>
>For example:
>
>1. detect how many and which clients are on-line
>2. how to deal with the connection drop in the communication.

When you start to worry about these things, it is time to drop TCP/IP
and use UDP or raw messages, since the TCP layer just complicates the
issues when the connection is going to fail.

>Of course these are application specific, but I think there must be
>already some patterns there.

The Ethernet system is just an other physical connection comparable to
RS-232/422/485, so exactly the same principles can be applied as to
any serial line protocol when using UDP or raw messages. 

The most common is to do something application specific when the
communication partners fails to respond within a predefined time
(timeout). For sockets, the select() call with a timeout parameter
before attempting to read anything is quite useful.

Paul

Steven P wrote:
> Hi
> 
> I have a project to connect several control boxes with a TCP based
> network. The TCP/IP stacks is  available.
> 
> I would like to know if there are  some design patterns in "C", which
> deal with the identification of other clients in a TCP Network( such as
> broadcasting every several secondes), establishment of link and flow
> control/Error control.  

The MS version of networking relies on hosts to announce themselves
periodically.  This results in lots of chatter as the size of your
network grows, etc.

You have to decide how quickly you need to discover new hosts.  And,
if you intend to use a different protocol to discover a LOST host
(instead of relying on broken connections, etc.

You have to decide how much overhead you want to devote to these
issues -- both in terms of network bandwidth AND CPU cycles.

You have to decide if you want a distributed or a centralized
algorithm.

Etc.

But, more fundamentally, you have to decide *why* you need this
sort of network discovery instead of *confguring* your network
explicitly.

I.e. do you expect to just plug a node in and have the "system"
magically recognize the new node AND know what it's capabilities
are (in terms of your application) AND how it integrates with other
nodes?  At the very least, you need to assign unique IP's/netmasks
to each node and ensure there are no conflicts (assuming we can
ignore any bridges/routers/gateways for the time being).   If
you intend to avoid this by using something like DHCP, then
you can have the DHCP server keep track of which leases it has
let and, from that, "know" what's on the wire, etc.

Your question is too vague for a better answer  :<

--don

> The Ethernet system is just an other physical connection comparable to
> RS-232/422/485, so exactly the same principles can be applied as to
> any serial line protocol when using UDP or raw messages.

That is quite right. Do you have some URL pointing to some common
patterns ( or techniques) using "serial line protocol", or books?


Thanks

Steven

On Sat, 07 Oct 2006 10:00:09 -0700, Don <none@given> wrote:

>I.e. do you expect to just plug a node in and have the "system"
>magically recognize the new node AND know what it's capabilities
>are (in terms of your application) AND how it integrates with other
>nodes? 

If the potential new nodes are all from the same manufacturer and thus
have a unique MAC address assigned for that manufacturer, you could
scan all MAC addresses assigned to that manufacturer and based on
detected MAC addresses, set the IP address.

Paul

Paul Keinanen wrote:
> On Sat, 07 Oct 2006 10:00:09 -0700, Don <none@given> wrote:
> 
>> I.e. do you expect to just plug a node in and have the "system"
>> magically recognize the new node AND know what it's capabilities
>> are (in terms of your application) AND how it integrates with other
>> nodes? 
> 
> If the potential new nodes are all from the same manufacturer and thus
> have a unique MAC address assigned for that manufacturer, you could
> scan all MAC addresses assigned to that manufacturer and based on
> detected MAC addresses, set the IP address.

OUI's are *big* (or, "small" -- depending on how you look at it  :> )
Even pinging each address once per second could take YEARS (?) to
cover an entire address assignment.

And, you have to deal with the possibility that the node you just
pinged may have been offline -- and is now *online*... waiting for
you to "come around again" ("on the gi-tar... with FEELING").

Much depends on the *logical* organization/structure of the
system.  Without knowing that, it's pointless to speculate on
how you "could" do it -- as there may be relatively simple
techniques that already are present (or could be) as a
consequence of the implementation (e.g., my DHCP notes)