|
Happy New Year from Israel!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
#Worldle #343 1/6 (100%)
π©π©π©π©π©π
https://worldle.teuteuf.fr
easy one
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
but for some definitions in ancient English styles, I can not grasp solidly.
Can I post my question here?
diligent hands rule....
|
|
|
|
|
"All the best mathematics books are in German." -- My father, quoting one of his college professors (1950s era)
|
|
|
|
|
I for one would love to see them.
PartsBin an Electronics Part Organizer - An updated version available!
JaxCoder.com
|
|
|
|
|
ditto
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
Yes, but only if you give equal time to Leibniz, and include your critical analysis of how "The System of the World" by Neal Stephenson uses the Newton/Leibniz "controversy" as a key plot element.
Β«The mind is not a vessel to be filled but a fire to be kindledΒ» Plutarch
|
|
|
|
|
That's easy. Synopsis as critical analysis: sheep ked/open sinus blood/high magnification confocal binocular/2000W stage lighting.
... peace following war.
|
|
|
|
|
Southmountain wrote: Can I post my question here? We won't know until you try.
/ravi
|
|
|
|
|
Wordle 560 4/6
β¬β¬π¨π¨β¬
π¨π©β¬β¬π©
β¬π©π©β¬π©
π©π©π©π©π©
|
|
|
|
|
Wordle 560 5/6
π¨β¬β¬β¬β¬
π©π©β¬β¬π¨
π©π©β¬π¨β¬
π©π©π©β¬π©
π©π©π©π©π©
|
|
|
|
|
Wordle 560 4/6
β¬π¨π¨β¬β¬
π¨π¨β¬β¬π¨
β¬π©π©β¬π¨
π©π©π©π©π©
|
|
|
|
|
Wordle 560 3/6
π¨β¬β¬β¬β¬
β¬π¨π¨π¨π©
π©π©π©π©π©
Lucky guess - 1:3 chance there.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
β¬β¬π¨π¨β¬
β¬π©β¬β¬π¨
β¬π©π©β¬β¬
π¨π©π©β¬π©
π©π©π©π©π©
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming βWow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 560 4/6
π¨β¬β¬β¬β¬
β¬π©β¬β¬β¬
π©π©π©β¬π©
π©π©π©π©π©
Get me coffee and no one gets hurt!
|
|
|
|
|
Wordle 560 6/6
π¨β¬β¬β¬β¬
β¬β¬π¨β¬β¬
β¬π¨β¬π¨β¬
β¬π©π©β¬π©
π©π©π©β¬π©
π©π©π©π©π©
Just made it
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
If you want a "cooler" version of this song, try Anglina Jordan: Bille Jean[^]
(Sure, she is a girl. Nevertheless, I think that the character of her voice fits the "boy's lyrics" quite well! For the curious ones: She was 15 years old when making this recording.)
|
|
|
|
|
...at least, it doesn't involve any code. It's more of a "would you do it this way" type of question...
Over a decade ago, I wrote a small app that needed to broadcast simple notifications to other systems across my LAN. I came across mailslots, a mechanism that's been built into Windows for years, and both client and server samples were trivial enough to be considered no-brainers.
A few days ago, being on holidays, I spent a bit of time reviewing that code, rebuilding it using newer versions of .NET, and implementing some minor fixes (completely unrelated to mailslots).
But it got me thinking: Are mailslots still a worthwhile mechanism? I've never come across any formal documentation as to how long Windows would still be supporting them for, and on Windows 10/Server 2022, my code still works rather nicely. It's simple and elegant, low-overhead, and does the job.
I guess it could boil down to just that, "does it do the job", and leave it at that. Still, I'm curious - does anyone know of a reason to proactively avoid this mechanism? It's using UDP, but I've never lost a single packet (and even if it did, it's not vital to any operation). It's using the standard Windows file share port, I believe, so it's unlikely to be blocked, at least within a private LAN. It's not inherently secure, but it's not transporting any confidential data. And even if it had to, there's plenty of ways a message could be encrypted.
What argument might you use to convince someone to use another mechanism? The current (?) MS documentation on mailslots also mentions named pipes and Windows Sockets. Sockets aren't exactly trivial (or rather, not as trivial), and TBH I've never tried to use named pipes so I'm not in a position to make an honest judgement.
I guess I'm just fishing for pro/con arguments. What say you?
|
|
|
|
|
Scalability and async. And maybe more interesting.
Asynchronous message-based communication | Microsoft Learn
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Complete overkill, I'm afraid, for the needs of this app. See my reply to raddevus below.
|
|
|
|
|
I remember reading about mailslots when Windows NT came out. Over the years it has been one of their few IPC mechanisms I haven't tried. That was not for any particular reason. I just found preferable alternatives every time I looked. Today, I would still be unlikely to use it but this is primarily because I have some familiarity with the alternatives.
I think the two primary arguments I have against it are I am unaware of a compatible facility on Linux so it could be problematic to talk to a Linux box with it (or a Mac box), and I would prefer to use a raw sockets implementation instead of something built a layer or two on top of sockets. I have worked with sockets enough over the years that I would just use that and there are some very nice wrapper classes for them available with my favorites being at this site.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: some very nice wrapper classes
That's probably what was missing at the time I decided against using sockets.
Mailslots are so simple they don't need even a thin wrapper library.
|
|
|
|
|
How fast can you explain how to use the mailslots system to someone else?
Now, here is an opposing idea that I'm putting forth as a much simpler idea.
Since this is within the confines of one Business Entity I'm suggesting that there is a central SQL Server (or other DBMS ) running on site.
How about if you broadcast a message (write a request to a table) that each service which wants to use the request simply reads it?
Think about the DBMS resiliency that you get. It's always running, failed writes are traceable etc. But it is also a "common" system for devs. Most devs can write an entry (insert) and read entries (select) easily from any language.
The table might look something like:
Subscribers Table
ServiceName, SubscriberServiceName, Active
ServiceName = publisher
SubscriberServiceName = subscriber
WorkRequest Table
SubscriberServiceName, Status, FunctionToRun, Created, Updated, Active
SubscriberServiceName = subscriber
Status = O (Open) C (Complete), E (Error)
FunctionToRun (the individual service will know what this is)
Now, the Publisher Service simply :
1. does select for all services that are subscribed to the service (Subscribers table)
2. writes a WorkRequest for each of those subscribers
Each Subscriber polls (yes this is polling) DB and checks WorkRequest for any O(pen) records that match it's SubscriberServiceName.
When it finds those it runs the functionality.
Now, everything simply depends upon writing to two tables.
Benefits
You get all the uptime benefits of SQL Server (or other Enterprise DBMS) and you can tell another dev how to use your system in minutes.
You tell Dev:
1. write a subscriber record into the subscribers table that matches your apps name (needs to be unique over company) -- this is a one-time thing. Also, the service can unsubscribe at any time.
2. Poll the database at X interval for your app and query the WorkRequestTable for O(pen) records -- so the service doesn't accidentally do the work twice.
3. When you complete the entry for the WorkRequest and succeed, write a C(losed) value in Status.
3a. If your process fails write a E(rror) in Status to indicate a failure.
Shoot Holes In This
You can shoot holes in this idea, but keeping the this simple for your devs is a strong motivator.
Also, anyone can come along and understand it. I have no idea how to use mailslots.
Also, any type of service (web app, windows forms, linux app, java app) can access the database and leverage this messaging functionality.
That's my 52 cents on the subject.
One last thing, keep in mind that a Enterprise DB Server is basically always up and if it isn't then there is a major problem at the enterprise which must be fixed by Hardware people or DBA etc.
That means you wouldn't be able to process records in this system but that would be "fine" because your point of failure is the DB which others keep running.
If you have a network failure in the current system then you have to handle all of that and it would be problematic and difficult to research (probably). Where did your failed message go?
Since my proposal depends upon Optimistic Concurrency (Implementing Optimistic Concurrency (C#) | Microsoft Learn[^]) and the DBMS you will basically never lose a message and you don't have to manage much.
Basically my point is that you get this all for free. If the DB has an issue you can't read the record and do the work, which indicates other problems.
modified 30-Dec-22 12:36pm.
|
|
|
|