C program to communicate over ethernet

[polkid]

I need some guidance here please!

I need to write code to talk from a PC to a DAQ type of thing, and have
there be a stream of data back and forth between them. I don't want to
use TCP because I dont need all those headers and whatnot, that's just
extra information. This is just between 2 machines, no routing needed.

So where do I look? How do I start? Everything I find talks about IP
addresses and stuff. I just need to stream bytes over ethernet.

(A side note, is sockets() just a TCP thing?)

Thanks!

Wade Polk

 

[EventHelix.com]

I need some guidance here please!

I need to write code to talk from a PC to a DAQ type of thing, and have
there be a stream of data back and forth between them. I don't want to
use TCP because I dont need all those headers and whatnot, that's just
extra information. This is just between 2 machines, no routing needed.

So where do I look? How do I start? Everything I find talks about IP
addresses and stuff. I just need to stream bytes over ethernet.

(A side note, is sockets() just a TCP thing?)

I would strongly recommend using UDP or TCP to transport the data. In
all other cases you will end up with a lot of code that may not be
readily portable to other platforms.

Use socket APIs to write your program and it will be easily portable to
any platform.

 

[SM Ryan]

# > I need some guidance here please!
# >
# > I need to write code to talk from a PC to a DAQ type of thing, and have
# > there be a stream of data back and forth between them. I don't want to
# > use TCP because I dont need all those headers and whatnot, that's just
# > extra information. This is just between 2 machines, no routing needed.
# >
# > So where do I look? How do I start? Everything I find talks about IP
# > addresses and stuff. I just need to stream bytes over ethernet.
# >
# > (A side note, is sockets() just a TCP thing?)
#
# I would strongly recommend using UDP or TCP to transport the data. In
# all other cases you will end up with a lot of code that may not be
# readily portable to other platforms.
#
# Use socket APIs to write your program and it will be easily portable to
# any platform.

Even over 'simple' connections, there is so much overhead dealing
with unusual conditions, synchronisation, bufferring, etc that you
get for free if you use TCP. Unless you really know what you're
doing or dealing with real strange system, you are far better off
learning the existing library instead of writing your own.

Besides the TCP interfaces your system might provide, there are
other libraries like the Tcl C API which are even easier to use
and more portable.

 

[polkid]

Thanks! I guess I just didnt want to use TCP because the program
doesn't need to be portable. It's going to be written to work between
two computers and no others ever. But I'll take your advice and write
it using TCP and see how it goes.

 

[Tom St Denis]

I need to write code to talk from a PC to a DAQ type of thing, and have
there be a stream of data back and forth between them. I don't want to
use TCP because I dont need all those headers and whatnot, that's just
extra information. This is just between 2 machines, no routing needed.

UDP?

Failing that you can also try IPX. It has no routing.

So where do I look? How do I start? Everything I find talks about IP
addresses and stuff. I just need to stream bytes over ethernet.

Um, you could send broadcast UDP packets and listen on 0.0.0.0

(A side note, is sockets() just a TCP thing?)

No. In Linux/BSD you can use the sockets API to deal with raw IP, raw
802.3, raw whatever. YMMV as the lesser portable methods are less
documented.

Tom

 

[Walter Roberson]

I would strongly recommend using UDP or TCP to transport the data. In
all other cases you will end up with a lot of code that may not be
readily portable to other platforms.
True.


Use socket APIs to write your program and it will be easily portable to
any platform.

False though.

Readily portable to "other platforms" != "portable to any platform".
Sockets are not universal, and are not POSIX compliant on at least
one major popular operating system.

Using sockets is a lot better than rolling your own, which is unlikely
to get you to very many platforms. But no matter which API you use,
there will be some platform that it won't work on, even if said platform
has some kind of ethernet communications.

 

[Joe Wright]

Thanks! I guess I just didnt want to use TCP because the program
doesn't need to be portable. It's going to be written to work between
two computers and no others ever. But I'll take your advice and write
it using TCP and see how it goes.

If you continue networking, learning TCP will prove useful. Doing it
some other way might be interesting but not likely useful in the future.

 

[robertwessel2]

Failing that you can also try IPX. It has no routing.

While seriously OT...

Since when? IPX has been routable since it was derived from XNS 20+
years ago. Admittedly routing was not a standard feature of 1.x
versions of NetWare, but was certainly part of 2.0a (circa 1986), and
IPX routing has been available in numerous non-Novell products.

 

[Tom St Denis]

While seriously OT...

Since when? IPX has been routable since it was derived from XNS 20+
years ago. Admittedly routing was not a standard feature of 1.x
versions of NetWare, but was certainly part of 2.0a (circa 1986), and
IPX routing has been available in numerous non-Novell products.

IPX basically just used the MAC addresses IIRC. It was like UDP where
you had a port which identified the service.

MAC addresses are not routable because they are not hiearchical. Sure
you can manually map MAC addresses to given ports on a switch (for
instance, switches do this automatically as it discovers source
addresses) but it isn't scalable.

If there was any routing in IPX it was totally manual and host based
instead of network based like IP.

Tom

 

[robertwessel2]

IPX basically just used the MAC addresses IIRC. It was like UDP where
you had a port which identified the service.

MAC addresses are not routable because they are not hiearchical. Sure
you can manually map MAC addresses to given ports on a switch (for
instance, switches do this automatically as it discovers source
addresses) but it isn't scalable.

If there was any routing in IPX it was totally manual and host based
instead of network based like IP.

No, IPX used a two part address, a 32 bit network number and a 48-bit
host number (plus a 16 bit port). On LANs with Ethernet-style MACs,
the host number was just assigned to the MAC, although in some (rare)
circumstances a manual assignment was used. In short, this was roughly
equivalent to an 80 bit "IP" address with a fixed "/32" subnet mask.

Non-routing machines normally required no address configuration (beyond
what the LAN hardware required - for example Arcnet would require that
you set the 8-bit "MAC" address on each card, either in hardware or
software). Non-routing hosts would learn their network number from a
router on that LAN (a particular broadcast query). Routers, of course,
*did* have to be configured with the correct network number on each
NIC.

Novell eventually set up a registry of network number assignments,
which assigned globally unique network number ranges (IOW,
"subnets" of the network number).

FWIW, a minor variation of RIP was the routing protocol of choice for
early XNS and IPX implementations, although Novell eventually migrated
to an OSPF-like link-state protocol (NLSP) somewhere in the NetWare 3.x
days.