🚀 go-pugleaf

Alan Fontaine writes:
> This leads  to some stupid things.  An example : messages  and files are
> handled by the same monolith, so, unless there are things I am not aware
> of, messages follow  the same routes as files. While  a multiple hop S&F
> strategy is fine for files, it does  not make any sense for messages, to
> which it only adds delay  and processing overhead while gaining nothing,
> since a message is dropped at  the first down link encountered.....

Indeed messages are following the same routes as files, but they are
not "Stored", in the sense of putting them to disk or something.  In
this sense, they are simply handed over by the communication software,
as "esoteric packets" - if you think of it, it makes sense to do it.

> I am
> also wondering  (but have no  definitive idea) if it  is wise to  try to
> multiplex several data streams on a single TCP connection. The tradition
> seems to go  in the opposite direction (99% of  the FTP sessions involve
> at least two connections between a  pair of hosts, for example), for the
> benefit  of simplicity  in the  application  protocols if  for no  other
> reason.

It is definitely unwise to go into trouble multiplexing streams over
a virtual link that is already multipexed. Of course. Had NJE-like
service been developed over a TCP-like protocol, it would most likely
have used several TCP streams. I think most people agree that NJE over
TCP (why, BTW, is it refered to as NJE over IP?) is not an optimized
solution in any way, just an intermediate ad-hoc bridge between
two very different network services.

All in all, I do agree that NJE over TCP is not a way to go, in the
*long* run. Definitely, NJE-like services *can* be developed in the
TCP/IP suite. The thing is, that they are currently missing (I do
not consider TALK to be similar to the NJE unsolicited-message/command
service - and this is not to say any of them is superior. They are
just not similar services).

Doron