Re: [cc65] cc65 + tcp/ip howto and/or example

Hi Gábor,

> It would be so nice if cc65 has some kind of library for some TCP/IP so many
> new projects can be born using tcp/ip then. Sure, I can use Contiki, but now
> I'm thinkin in "simple individual" (not within contiki) programs utilizing
> TFE and/or RR-Net for example.

I'm not sure what you are refering to with "within Contiki":

If you mean the Contiki O/S with its own desktop than you should know
that this was Contiki 1.x. In Contiki 2.x you write "individual"
programs loaded from your DOS running in full screen mode (or doing
their own user interface).

If you mean that Contiki isn't just a library you call into when you
like but rather a framework you embedd your code into than this is
because it is the *only* way to do TCP in a way efficient enough for
cc65 targets. Just a few of the several reasons:

- An event/callback architecture implicitly serializes access to
resources. Otherwise explict locking and/or multiplication of
resources would be necessary.

- Have you ever written a GUI application? The GUI core calls you when
your screen area needs to be (re-)drawn. This makes perfect sense as
in most cases the code to do so is the same for drawing your screen in
the first place. So there's no overhead on the application side but
the GUI core can avoid to buffer your screen content offscreen. In
many cases the GUI applications just send themselves a redraw event
when they want to update the screen. uIP is using the very same
paradigm for networking: If a packet needs to be resent it just calls
the application to recreate it! In most cases this is no problem at
all for the application but allows uIP to go without any
buffering/copying. An exception is the web server on the C64 serving
disk files as they allow only sequential access. Here the application
buffers the last frame - still not worse than uIP doing it.

> Unfortunately, I am not so good in deep
> TCP/IP internals (yet?), I am experienced with writing servers/clients under
> UNIX-like OSes, though I doubt it can be easily adopted for cc65 (I mean the
> same API as Unices use) because of lacking enough system resources for a
> UNIX-like API (let's say POSIX, I mean now about socket(), connect(),
> listen() and similar functions).

Exactly. Those APIs only work in a reasonable way in environments
where "everything is a file" so you can put its handle into select().
Because otherwise you can't multiplex I/O on several network streams,
the user interface, ... That is one reason why you don't get far with
those APIs i.e. on Windows...

But even on UNIX-like OSes: Applications tend to be either
thread-or-fork based or select() based. The thread-or-fork approach is
supposed to perform better - but would you really want to program cc65
targets that way? And when you look at a select() based application
than you're basically back at event driven programming with select()
being your event source you act upon - don't you?

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.