56200+ entries in 0.031s
mircea_popescu: hey, wasn't proclaimed
the golden veal. merely worth documenting.
a111: Logged on 2017-05-23 02:41 asciilifeform: per dijkstra's 'testing can demonstrate
the presence of bugs, but never
their absence'
a111: Logged on 2018-12-14 01:57 mircea_popescu:
tbh, a recuperative scholarly series on sns would be most apt use of scholar's
time.
mircea_popescu: tbh, a recuperative scholarly series on sns would be most apt use of scholar's
time.
☟︎ BingoBoingo: I dunno if
that will work with your Russian physiology
mircea_popescu: but "here's
the 256 serpent keys i want you
to pick amongst" is not.
mircea_popescu: eg, client can (and well behaved client is expected
to) send multiple serpent keys upon first connection.
diana_coman: mircea_popescu, well, in principle you can run out of space and
that'll raise an exception and program dies :D
diana_coman: they will just get potentially stuck waiting for queue
to empty
diana_coman: aha;
thin sender/receiver can't do anything about it anyway
mircea_popescu: do
they check and signal when queue is fuller
than some percentage << i expect
the
task manager will have
to do
this. not
the wrapper, no.
diana_coman: because
they are non-client/app specific really
diana_coman: given
the decision for
thin, it makes sense, yes
mircea_popescu: not like can't separate later. but generally speaking
the
tendency of v-trees is integration.
mircea_popescu: "I'm not even sure whether a sender/receiver should be in fact part of smg_comms" << while
this has merit, i'd still keep
them in.
mircea_popescu: ok, so
the idea here is,
that while maintaining different code on different boxes is costly and undersirable, nevertheless
that is mitigated by
the relative ease of
the genericization/prototyping mechanism in ada ; whereas single queue model, as logically
tempting as it may be, is costlier
than it seems (not necessarily because insertion can't be o1, but still, machinery involved).
diana_coman: uhm, it's "different" in
the sense of one parameter
diana_coman: you don't have
to deploy rsa sender on s box
mircea_popescu: and
then if we get
two boxes,
there's gonna be an allocated and always-empty queue on each of
these.
diana_coman: "as asciilifeform describes" aka 1 item put/get at a
time; 2 different queues, one for rsa one for s
mircea_popescu: well, serpent processor wants a serpent item
to process.
diana_coman: my implementation is just a bounded queue fifo, 1 item at a
time in /out; and yes, I looked again at Ada's standard stuff and I could use I
think a bounded_synchronized_queue container but
then it forces me
to put/get full structure
mircea_popescu: yes. diana_coman mind explaining how
this works ? so, queue has 55 elements, 22 of which rsa packets. now what happens ?
diana_coman: i.e. yes, it could have been implemented as mircea_popescu describes if I didn't aim for
this specifically
diana_coman: mircea_popescu,
the way I implemented it it's as asciilifeform says but
the reason it is *this* data structure is because of intended use so linked
to above
mircea_popescu: asciilifeform afaik you can "get
top X" rather
than "get
top" neh ?
diana_coman: mircea_popescu,
that's precisely why I made it
that way; I suppose it's not clear
there at all but yes - because processing of rsa/s is meant
to be easily and entirely separated physically, aka machines
mircea_popescu: but re your q :
these 6 workers pick rsa from queuer ; and
these 3 pick serpent from queue.
mircea_popescu: this machine for serpent,
this machine for rsa, is
the model here.
mircea_popescu: two kilobytes are
two kilobytes.
the advantage of doing it
the way she does it is
that if you get
two machines later, you can run
this code unmodified.
the disadvantage is absent, because
two kilobytes are
two kilobytes, what do yo ucare if "separate"
mircea_popescu: asciilifeform no, counterintuitively hers is
the right cut.
mircea_popescu: hm. i suppose
this is okay, really. scalable enough, if eventually we decide
to get a s and a r machine,
they'll just have
their own queues and
that's it.
mircea_popescu: "this is needed for
the same reason as
the generic at UDP lib previously -
to allow one
to store Serpent messages or RSA messages while maintaining
them clearly differentiated" << why are you putting ducks and geese in
the same line
though ?
mircea_popescu: diana_coman yes, certainly should provide whatever diagnosis
tools and equipment you want. i don't want
to fill
that in yet, it'll... come
to you, as it happens :)
diana_coman: anyway, rewinding:
thin sender/receiver wrappers; on udp lib eggog, program dies (hopefully more gracefully
than disgracefully but still death)
mircea_popescu: in
the other line, have you played with ada
threads any ? are you friends ?
mircea_popescu: "wtf does he mean ignore, isn't
that just resend???" sorta
thing ?
a111: Logged on 2018-12-13 19:39 mircea_popescu: diana_coman you proposing it'd be better
to resend
than ignore ?
mircea_popescu: "there are not enough errors you can fix for
the machinery
to fix errors be worth having around".
mircea_popescu: i guess
this is a spot you;ll have
to proceed on faith,
diana_coman: asciilifeform, I don't know if/that
that is indeed
the only
thing
that can kill
the socket; and
testing won't quite
tell me either
mircea_popescu: and
this is a fundamental assumption baked into
the udp spec etc.
diana_coman: right,
that wasn't
the proposed approach at any
time
mircea_popescu: no, what i'm saying is
that with udp it is ~never worth "Retrying" in
the
tcp sense.
diana_coman: that was my original meaning but
then I got
the impression you said
the wrapper should ignore so
then...it should keep
trying?
mircea_popescu: "returns" in
the sense of "return error, let machinery stop"