|
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.
|
|
|
|
|
I appreciate the time and effort that obviously went into that post. 
But, there's 2 things that came to mind in light of that response.
a) A DB is complete overkill. If I miss a message, I miss it - it's not the end of the world. I'm comfortable enough, after all, using this UDP-based protocol, which never guarantees delivery.
b) While it's not necessarily vital to get the message at all, if I do get it, then it has to be done in a timely fashion - single-digit seconds. 10 seconds is definitely too long. It can't be minutes, and it certainly can't be hours. Otherwise getting the message that late is pointless and I might as well not have received it at all. If I have to poll a database, then the overhead of querying it every 10 seconds sounds like costly operation.
===
More context, to put things into perspective:
I wrote the original app back in 2009 (according to source file timestamps, before I started bringing it up to date). Back then, more and more people started calling my landline from cell phones - and few of them show caller ID - still to this day (although the phone number is displayed, the name is rarely included). Some of these numbers are in completely different area codes, despite (say) being next door neighbors, and I'm just getting worse in remembering people's phone numbers.
So I got a USB dial-up modem and hooked it up to my phone line, and the USB port to a computer I happen to have running 24/7. The app I wrote monitors the COM port, and while the modem never picks up, it does get Caller ID notifications when a call comes in. While the name might not be there, the number almost always is. So in (almost) real-time, my app looks up phone numbers from my Windows contacts list (already read and cached), and then (this is where mailslots come in) uses the mailslot mechanism to broadcast a notification to all systems I have at home that run the client portion of it. The client simply waits for notifications to come in through a mailslot, and as soon as one is received, brings up a popup showing who's calling, including the caller name that has been looked up.
So this is where my reasoning comes from. It's not terribly important that I get the notification at all. But if I have to poll a DB to look for those notifications, then I can't afford to only do it every 30 seconds (I need to know as soon as the phone rings; it's pointless otherwise).
The whole thing is merely a convenience, so when the phone rings, and IT can't show the full caller ID info, then at least the computer I'm using at the time does show it, before I decide to pick up the phone (or not).
Maybe I should've included all of this in my original post, but that would only have made it that much longer, and ultimately it strays away from the whole mailslot discussion.
|
|
|
|
|
dandy72 wrote: If I have to poll a database, then the overhead of querying it every 10 seconds sounds like costly operation.
To make it very clear I am not suggesting that you should use a database.
However that statement sounds like something that would have applied when you first wrote the app. But not now.
|
|
|
|
|
And which one of all your questions is not a programming question?  
|
|
|
|
|
I'd say that "Can we really rely on Windows providing support for mailslots for the foreseeable future?" not to be a programming question.
|
|
|
|
|
Thank you.
You put it more succinctly than I ever could
But then, context is everything.
|
|
|
|
|
0x01AA wrote: And which one of all your questions is not a programming question?
The lack of "URGENT SEND CODEZ PLZ!!" in my entire message disqualifies it. 
|
|
|
|
|
I'd like to put in a good word for Raymon Chen's book, The Old New Thing, which is a selection of his blog posts in the blog of the same name (The Old New Thing[^]. (If you don't want to spend your money on the book, you can find it all on the blog, but it is so rich that you will then spend quite a few hours of your time instead.)
Quite a few of the stories in the book tell about the efforts of MS to retain backwards compatibility - sometimes to extreme lengths. Most of us would say that a few of the cases goes way over the edge. (It is funny reading, anyway! )
My impression is that this 'backwards compatibility at all costs' has been relaxed somewhat the later years. Yet, mailslots is a general mechanism, used by countless applications; we are not talking about saving a single application (as was the case in some of the stories in the book). The code is there to handle it; the cost of keeping it there is quite limited. The cost of removing it and thereby killing countless existing applications is probably magnitudes larger.
So I wouldn't be too worried. My guess is that if you read the book, you won't be worried either.
|
|
|
|
|
ditto
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
That was my thought as well. They're unlikely to ever remove it...but it's still not something I'd rely on if I were to put together a brand new app...or anything particularly important.
|
|
|
|
|
Find out how many Microsoft Windows exe and services use them. That will help forecast longevity.
Olde Farte poste
I have not used “mail slots” but this name sounds suspiciously like “mailbox” and “network mailbox” from Digital Equipment Corp (DEC) VMS.
Some of the Devs that coded Windows NT kernel came from DEC.
|
|
|
|
|
Yeah, I was going to comment on that too.
As such, I would consider it ancient tech and probably not equivalent to anything in UNIX.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
