High-level network programming: is C language suitable for that?

[pozz]

I'll start a new application in a short time and I'm wondering if C
language is good enough for that.

The application will be simple: it should implement some TCP/UDP
protocols (like TFTP, BOOTP,...) with a simple GUI. It will run on
Windows platforms, but the possibility to run it on Linux would be nice.

Is C language suitable for this kind of applications? Which kind of
cross-platform libraries should I use to manage IP protocols and simple
GUIs? Could python or other high-level (script) languages be a better
choice?

[Heinrich Wolf]

"pozz" <pozz...@gmail.com> schrieb im Newsbeitrag
news:jnbudg$vhc$1...@nnrp.ngi.it...

Hi,

C is definitely suitable enough for network programming. In my profession I
created several networking daemon applications using K&R C on Unix / Linux.

Heiner

[ImpalerCore]

Wireshark is largely written in C, which should be enough to
demonstrate C's feasibility to handle networking applications. Just
depends on your comfort levels using whatever combination of GUI and
network frameworks that suits your fancy.

Best regards,
John D.

[Jens Thoms Toerring]

Of course, all this can be done in C (most scripting languages
are actually implemented in C, so everything you can do in
those languages can obviously be done in C). But note that C
has no "native" support for networking or graphics, thus the
need for additional (cross-platform) libraries (unless you're
keen to re-invent the wheel;-). For TFTP and other protocols
libcurl seems to be a candidate to take a look at. I don't
know about BOOTP (wasn't that obsoleted by DHCP?). For gra-
phics the only cross-platform library for C I know about is
GTK+ (but I never used it) - most other seem to require C++.

If using Python or some other scripting language would be pre-
ferable depends on what you want to do there, if you need max-
imum performance, and if you feel comfortable with that lan-
guage. Perhaps it might be a good idea to start with a scrip-
ting language and see if it does ok, otherwise you can still
re-implement the stuff in C, drawing on the experiences you
made.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de

[Malcolm McLean]

בתאריך יום חמישי, 26 באפריל 2012 17:50:57 UTC+1, מאת pozz:

C is an OK choice. basically you need ab it of logic, which you can do in any language with equal ease, and you need to call libraries to run the GUI and the network code.
C will take a bit longer to debug than a higher-level language, but on the other hand almost everyone knows it, and it doesn't provide funny features which tempt to mess about and play with the language's capabilities, rather than get the job done. The problem is the libraries. Qt is probably your library of choice if you want a windowing system that runs under both Windows and Linux. But I haven't used it myself. It's also unacceptably difficult to integrate a library with a C compiler. However, unlike other languages, C won't suddenly go obsolete on you.

[BartC]

"Jens Thoms Toerring" <j...@toerring.de> wrote in message
news:9vtng0...@mid.uni-berlin.de...

> pozz <pozz...@gmail.com> wrote:
>> I'll start a new application in a short time and I'm wondering if C
>> language is good enough for that.

> Of course, all this can be done in C (most scripting languages
> are actually implemented in C, so everything you can do in
> those languages can obviously be done in C).

By that argument, it can all be done in machine code or assembler too.

C *can* program just about anything, but it can be a lot easier and less
error-prone to just use a higher-level, more adept language.

--
Bartc

[pozz...@gmail.com]

Il giorno giovedì 26 aprile 2012 21:54:40 UTC+2, Jens Thoms Toerring ha scritto:
> pozz

> wrote:
> > I'll start a new application in a short time and I'm wondering if C
> > language is good enough for that.
>
> > The application will be simple: it should implement some TCP/UDP
> > protocols (like TFTP, BOOTP,...) with a simple GUI. It will run on
> > Windows platforms, but the possibility to run it on Linux would be nice.
>
> > Is C language suitable for this kind of applications? Which kind of
> > cross-platform libraries should I use to manage IP protocols and simple
> > GUIs? Could python or other high-level (script) languages be a better
> > choice?
>
> Of course, all this can be done in C (most scripting languages
> are actually implemented in C, so everything you can do in
> those languages can obviously be done in C).

Oh, yes. I know C is powerful enough to manage comple network
protocols and beautiful graphical interfaces. The questions was
related to a simple application where I don't want to loose
too much time to find a suitable network and graphic library and
fine tune them. C can do anything at the cost of greater complexity.

I'm asking if a high-level scripting language can be more effective
for simple tasks and applications.

> But note that C
> has no "native" support for networking or graphics, thus the
> need for additional (cross-platform) libraries (unless you're
> keen to re-invent the wheel;-).

Absolutely no, I want to reuse existing libraries.

> For TFTP and other protocols
> libcurl seems to be a candidate to take a look at. I don't
> know about BOOTP (wasn't that obsoleted by DHCP?).

I have to implement a sub-set of DHCP protocol, similar to the
original BOOTP. It's for an Ethernet firmware upgrade for
and embedded gadget.

> For gra-
> phics the only cross-platform library for C I know about is
> GTK+ (but I never used it) - most other seem to require C++.
>
> If using Python or some other scripting language would be pre-
> ferable depends on what you want to do there, if you need max-
> imum performance, and if you feel comfortable with that lan-
> guage. Perhaps it might be a good idea to start with a scrip-
> ting language and see if it does ok, otherwise you can still
> re-implement the stuff in C, drawing on the experiences you
> made.

Ok, thank you for your suggestions.

[Rui Maciel]

Malcolm McLean wrote:

> C is an OK choice. basically you need ab it of logic, which you can do in
> any language with equal ease, and you need to call libraries to run the
> GUI and the network code.

It's worth mentioning that it's quite possible, if not desirable, to
implement stuff such ass protocol handling as a separate component. This
means that it's quite possible to use the C programming language to develop
protocol handling while employing some other programming language to
implement the GUI.

This may add a bit of complexity to a project, but it's the price to pay to
be able to get the best of both worlds.


Rui Maciel

[nick_keigh...@hotmail.com]

On Thursday, April 26, 2012 8:54:40 PM UTC+1, Jens Thoms Toerring wrote:

> pozz wrote:

> > I'll start a new application in a short time and I'm wondering if C
> > language is good enough for that.

C's pretty much "good enough" for anything. Could you produce your application quicker using some other language? Maybe.

> > The application will be simple: it should implement some TCP/UDP
> > protocols (like TFTP, BOOTP,...) with a simple GUI. It will run on
> > Windows platforms, but the possibility to run it on Linux would be nice.
>
> > Is C language suitable for this kind of applications? Which kind of
> > cross-platform libraries should I use to manage IP protocols and simple
> > GUIs? Could python or other high-level (script) languages be a better
> > choice?

python is certainly worth a look. It comes "out of the box" with socket and GUI libraries. It'll also run on multiple platforms, probably without change. Python can be a bit slow (which may not matter).

> Of course, all this can be done in C (most scripting languages
> are actually implemented in C, so everything you can do in
> those languages can obviously be done in C).

this is a theoretically true but practically useless.

*All* real-world programming languages are "turing complete". Which (loosly) means if it can be programmed then it can be programmed in that language. We could implement python in COBOL (if we enjoyed kicking dead whales down beaches) but it wouldn't be fun.

> But note that C
> has no "native" support for networking or graphics, thus the
> need for additional (cross-platform) libraries (unless you're
> keen to re-invent the wheel;-). For TFTP and other protocols
> libcurl seems to be a candidate to take a look at. I don't
> know about BOOTP (wasn't that obsoleted by DHCP?). For gra-
> phics the only cross-platform library for C I know about is
> GTK+ (but I never used it) - most other seem to require C++.

openGL, Qt

> If using Python or some other scripting language would be pre-
> ferable depends on what you want to do there, if you need max-
> imum performance, and if you feel comfortable with that lan-
> guage. Perhaps it might be a good idea to start with a scrip-
> ting language and see if it does ok, otherwise you can still
> re-implement the stuff in C, drawing on the experiences you
> made.

yes that is a good idea. You may get something working much quicker in Python.

[pozz]

Il 27/04/2012 16:27, nick_keigh...@hotmail.com ha scritto:
[...]

>> For gra-
>> phics the only cross-platform library for C I know about is
>> GTK+ (but I never used it) - most other seem to require C++.
>
> openGL, Qt

QT? I knew QT was for C++ and not C language.

[Jens Thoms Toerring]

nick_keigh...@hotmail.com wrote:
> On Thursday, April 26, 2012 8:54:40 PM UTC+1, Jens Thoms Toerring wrote:
> > Of course, all this can be done in C (most scripting languages
> > are actually implemented in C, so everything you can do in
> > those languages can obviously be done in C).

> this is a theoretically true but practically useless.

Well, the OP was asking "if C language is good enough for that";-)

> > But note that C
> > has no "native" support for networking or graphics, thus the
> > need for additional (cross-platform) libraries (unless you're
> > keen to re-invent the wheel;-). For TFTP and other protocols
> > libcurl seems to be a candidate to take a look at. I don't
> > know about BOOTP (wasn't that obsoleted by DHCP?). For gra-
> > phics the only cross-platform library for C I know about is
> > GTK+ (but I never used it) - most other seem to require C++.

> openGL, Qt

I fear using OpenGL for a simple GUI might not be too
suitable since it's a rendering library and what you
want for most simple GUIs is a set of widgets you can
easily manipulate, which isn't what OpenGL meant for
if I didn't mis-understand its purpose. Qt is defini-
tely C++ and I guess it could be a real pain if one
would try to marry it to a C program...

[Rui Maciel]

Jens Thoms Toerring wrote:

> But note that C
> has no "native" support for networking or graphics, thus the
> need for additional (cross-platform) libraries (unless you're
> keen to re-invent the wheel;-).

That depends on what's your definition of "native" support. There is a
considerable number of graphics and networking libraries which provide a C
API and are extensively used. For example, OpenGL, POSIX sockets and GTK
come to mind.


Rui Maciel

[Jens Thoms Toerring]

Rui Maciel <rui.m...@gmail.com> wrote:
> Jens Thoms Toerring wrote:
> > But note that C
> > has no "native" support for networking or graphics, thus the
> > need for additional (cross-platform) libraries (unless you're
> > keen to re-invent the wheel;-).

> That depends on what's your definition of "native" support.

I would consider to be "native support" everything that comes
with the C standard library. Everything else is, at least for
me, optional - it might exist but doesn't have to. In other
languages (Java, Python) this is part of the core language
(if that was a brilliant idea will be clearer in let's say
20 years from now;-).

> There is a considerable number of graphics and networking libraries
> which provide a C API and are extensively used. For example, OpenGL,
> POSIX sockets and GTK come to mind.

That's just what, in the rest of my post, I thought I had
mentioned;-) Though I wouldn't consider OpenGL to be a GUI
library ("simple GUI" doesn't evoke the association of "fast
3D rendering" for me but more "a few buttons and maybe a few
other useful widgets"). And I don't know, not being a Windows
programmer, how far the POSIX socket API is supported under
Windows, the OPs primary target - and my impression was any-
way that he wanted something more "high-level", that's why I
mentioned libcurl as something to consider for (at least) part
of his task.

[Malcolm McLean]

בתאריך יום שישי, 27 באפריל 2012 23:37:41 UTC+1, מאת Jens Thoms Toerring:

>
> That's just what, in the rest of my post, I thought I had
> mentioned;-) Though I wouldn't consider OpenGL to be a GUI
> library ("simple GUI" doesn't evoke the association of "fast
> 3D rendering" for me but more "a few buttons and maybe a few
> other useful widgets").
>

Open GL is a graphics library that mainly emphasises 3D rendering. However you seldom want an application that consists purely of a window containing a 3D scene. Open GL has a few 2D functions that allow you to add GUI type components on top of a window. The problem is you've got to write everything from scratch, such as the code to add the highlight and lowlight to your buttons. That tends not to matter so much for games, where you want the GUI to have a customised, fun look and feel. But for serious applications you want the reverse, the same look and feel as the desktop. So the Open GL route isn't a good one.

[nick_keigh...@hotmail.com]

On Friday, April 27, 2012 4:07:38 PM UTC+1, pozz wrote:

> Il 27/04/2012 16:27, nick_keighley ha scritto:
> [...]
> >> For gra-
> >> phics the only cross-platform library for C I know about is
> >> GTK+ (but I never used it) - most other seem to require C++.
> >
> > openGL, Qt
>
> QT? I knew QT was for C++ and not C language.

quite correct, I misremembered

[nick_keigh...@hotmail.com]

On Friday, April 27, 2012 6:07:08 PM UTC+1, Jens Thoms Toerring wrote:
> nick_keigh...@hotmail.com wrote:
> > On Thursday, April 26, 2012 8:54:40 PM UTC+1, Jens Thoms Toerring wrote:

> > > Of course, all this can be done in C (most scripting languages
> > > are actually implemented in C, so everything you can do in
> > > those languages can obviously be done in C).
>
> > this is a theoretically true but practically useless.
>
> Well, the OP was asking "if C language is good enough for that";-)

true, but implementing a script langauge before you start implementing the real problem may be an indication you've picked the wrong langauge. Though the Lisp metalinguists may disagree as might Fowler's "Domain Specific Languages"

> > > But note that C
> > > has no "native" support for networking or graphics, thus the
> > > need for additional (cross-platform) libraries (unless you're
> > > keen to re-invent the wheel;-). For TFTP and other protocols
> > > libcurl seems to be a candidate to take a look at. I don't
> > > know about BOOTP (wasn't that obsoleted by DHCP?). For gra-
> > > phics the only cross-platform library for C I know about is
> > > GTK+ (but I never used it) - most other seem to require C++.
>
> > openGL, Qt
>
> I fear using OpenGL for a simple GUI might not be too
> suitable since it's a rendering library and what you
> want for most simple GUIs is a set of widgets you can
> easily manipulate,

I've used an inhouse GUI tool that was built on top of OpenGL, though of course building that's extemly non-trivial!

There's GLUT that claims to be a GUI interface

which isn't what OpenGL meant for
> if I didn't mis-understand its purpose. Qt is defini-
> tely C++ and I guess it could be a real pain if one
> would try to marry it to a C program...
>
> Regards, Jens
> --
> \ Jens Thoms Toerring ___ j...@toerring.de
> \__________________________ http://toerring.de

[nick_keigh...@hotmail.com]

On Friday, April 27, 2012 11:37:41 PM UTC+1, Jens Thoms Toerring wrote:

> Rui Maciel wrote:
> > Jens Thoms Toerring wrote:

<snip>

> > There is a considerable number of graphics and networking libraries
> > which provide a C API and are extensively used. For example, OpenGL,
> > POSIX sockets and GTK come to mind.
>
> That's just what, in the rest of my post, I thought I had
> mentioned;-) Though I wouldn't consider OpenGL to be a GUI
> library

no it isn't. GLUT might be though.

("simple GUI" doesn't evoke the association of "fast
> 3D rendering" for me but more "a few buttons and maybe a few
> other useful widgets").

does everyone need "fast 3d rendering"? You can write some pretty fancy GUI applications without it. And he's doing network programming not Halo-N. A few buttons and forms and maybe a histogram or line graph would seem about it for network programming GUI. How complicated can you make BOOTP!

> And I don't know, not being a Windows
> programmer, how far the POSIX socket API is supported under
> Windows, the OPs primary target

Windows has its own socket interafec that is just slightly different from BSD (and I assume Posix). Just enough to be irritating. A fairly thin wrapper can hide the differences.

[TheGunslinger]

The latest version of QT appears to have separate libraries for C and
C++, and other languages.

It might just be how the defaults are pre-set, but it now lists C and
C++ separately.

MJR

[Robert Miles]

On 4/27/2012 5:37 PM, Jens Thoms Toerring wrote:
> Rui Maciel<rui.m...@gmail.com> wrote:
>> Jens Thoms Toerring wrote:

[snip]

>> There is a considerable number of graphics and networking libraries
>> which provide a C API and are extensively used. For example, OpenGL,
>> POSIX sockets and GTK come to mind.
>
> That's just what, in the rest of my post, I thought I had
> mentioned;-) Though I wouldn't consider OpenGL to be a GUI
> library ("simple GUI" doesn't evoke the association of "fast
> 3D rendering" for me but more "a few buttons and maybe a few
> other useful widgets"). And I don't know, not being a Windows
> programmer, how far the POSIX socket API is supported under
> Windows, the OPs primary target - and my impression was any-
> way that he wanted something more "high-level", that's why I
> mentioned libcurl as something to consider for (at least) part
> of his task.
> Regards, Jens

If you want the POSIX socket API under Windows, you might want
to investigate the Cygwin method of getting a Linux emulation
under Windows.

Robert Miles