On Monday, 21 February 2022 at 04:46:53 UTC, Chris Piker wrote:

Nice to hear, thnx! Actually I wrote D variant just to demonstrate
the idea to my collegue who is OOP/py guy and for whom it was hard
to understand C code.

:) I think WTFPL will do :)

I have very little experience in D and did not think about dub at all.

On Monday, 21 February 2022 at 07:00:52 UTC, eugene wrote:

If you want to add this file (or similar) to your sources, http://www.wtfpl.net/txt/copying/, but with your name in the copyright line I'd be happy to put the D version through it's paces and credit you for the basic ideas. I would not have thought of this formalism on my own (at least not right away) and want to give credit where it's due.

On Tuesday, 22 February 2022 at 20:19:39 UTC, Chris Piker wrote:

ok
http://zed.karelia.ru/0/e/edsm-2022-02-23.tar.gz
added 2 files, AUTHOR & LICENSE

On Tuesday, 22 February 2022 at 20:19:39 UTC, Chris Piker wrote:

As you might have been already noted,
the key idea is to implement SM explicitly,
i.e we have states, messages, actions, transitions
and extremely simple engine (reactTo() method)

Switch-based implementation of SMs is probably normal
for text/token driven SMs (parsers),
but is not good for event/message driven SMs (i/o and alike).

Remember main OOP principle, as it is understood by Alan Key?
It is message exchanging, not class hierarchy.
In this sense this craft is OOP twice, both classes and
message exchanging.

Another important point is SM decomposition & hierarchy
(I mean master/slave (or customer/provider) relation here,
not 'A is B' relation) - instead of having one huge SM
I decompose the task into subtasks and construct various SMs.
See for example that echo-server - it has 3 level hierarchy
of states machines:

LISTENER <-> {WORKERS} <-> {RX,TX}

When I wrote the very first version of EDSM engine
(more than 5 years ago, may be 7 or so), I...
I was just stuck - how to design machines themselves?!?
Well, the engine is simple, but what next? How do I choose states?
After a while I came to a strong rule - as long as I
want to send/recv some "atomic" portion of data,
it is a state (called stage in D version)!
Then as a result of elimination of code duplcation
I "invented" kinda universal RX and TX machine and so on...

In general I've found SM very nice way of designing
(networking) software. Enjoy! :)

On Wednesday, 23 February 2022 at 09:34:56 UTC, eugene wrote:

I remember you once mentioned a book that you used to learn this particular software design technique

Could you please name it again? Thank you in advance

On Thursday, 24 February 2022 at 06:30:51 UTC, Tejas wrote:

Wagner F. et al
Modeling Software with Finite State Machines: A Practical Approach

I've adopted some ideas from this book to POSIX/Linux API.
see also http://www.stateworks.com/

On Thursday, 24 February 2022 at 06:54:07 UTC, eugene wrote:

Ah! I also have EDSM for bare metal (AVR8 to be exact)
There is some description (in Russian), but you can look to the C-source

On Saturday, 19 February 2022 at 20:13:01 UTC, Chris Piker wrote:

I've remembered one not so obvious feature of TCP sockets behavour.
If the connection is closed on the server side
(i.e. on the client side the socket is in CLOSE_WAIT state),
write() will not fail, and data will go to no nowhere.

For this reason I have this (commented) code:

    bool connOk() {
        /*
        tcp_info tcpi; // linux specific, see /usr/include/linux/tcp.h
        socklen_t tcpi_len = tcpi.sizeof;

        getsockopt(id, SOL_TCP, TCP_INFO, &tcpi, &tcpi_len);
        if (tcpi.tcpi_state != TCP_ESTABLISHED)
            return false;
        */
        return true; // TODO
    }

I've dig up this in one of my progs (uploader to pg db):

/* check conn */
int dbu_psgr_ckcn_enter(struct edsm *me)
{
        struct mexprxtx_data *ctx = me->data;
        struct databuffer *ob = &ctx->obuf;
        struct databuffer *sb = &ctx->sbuf;
        int est = 0;

        if (ctx->sock > 0)
                est = csock_check_state(ctx->sock);
        if (!est) {
                /* save request to spare buffer */
                __dbu_make_request_copy(sb, ob);
                if (ctx->sock > 0)
                        log_inf_msg(
                         "%s()/DBU_%.3d - server has closed connection (fd %d)\n",
                         __func__, me->number, ctx->sock
                        );
                edsm_put_event(me, ECM1_CONN);
        } else {
                edsm_put_event(me, ECM0_SEND);
        }
        return 0;
}

I definitely did not want to loose data and so I am checking socket state before doing an INSERT request. I do not think it is 100% reliable, but I could not invent anything else.

On Thursday, 24 February 2022 at 08:46:35 UTC, eugene wrote:

https://stackoverflow.com/questions/26130010/avoiding-dataloss-in-go-when-writing-with-close-wait-socket

In my case (I was working with REDIS KVS at the moment)
exact scenario was as follows:

• prog gets EPOLLOUT (write() won't block)
• prog writes()'s data to REDIS ("successfully")
• prog gets EPOLLERR|EPOLLHUP

After this I see that I need to reconnect, but I've already send
some data which had gone to nowhere.

People sometimes recommend using usual non-blocking sockets,
but it is not the case.

On Thursday, 24 February 2022 at 06:54:07 UTC, eugene wrote:

Thank you so much!