• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1060
  • Last Modified:

Best way to communicate between two programmes (VB.NET)

Afternoon,

I'm looking for some advice on a project I am working on.

Presently I have 2 Console Applications (That run 2 separate API's one for the phone system ACD and one of the Call Recorder).

These churn through traffic and store information in a database ready for a client application (Windows Form) to obtain and use.

At present I am storing the information in a SQL Table and using calls to and from the SQL database in both the Console Applications and Windows Form application.

Is this best practice? In my experience under load the SQL Server could slow down and I don't like the idea of relying on DB requests to send the information back.

Is there a better way I could communicate between my Console Applications and my WIndows Form? I was potentially thinking that TCP messages from one to the other on a port would work and then use the Windows Form to use the 'stream' to perform its actions rather than getting the information from the database.

The reason being is ideally I'd like to have the 'database' as stored within memory for quicker retrieval than using the SQL DB.

Any and all advice is fully appreciated. Please give me an explanation as to why your suggestion is efficient as I would like to learn from this rather than just 'do'

Many Thanks!

James
0
Lynchie435
Asked:
Lynchie435
  • 7
  • 6
  • 4
  • +3
3 Solutions
 
QlemoC++ DeveloperCommented:
If running on the same machine, using Shared Memory is the best approach. If you need to cross the machine boundary, TCP is the way to go, but TCP requires to know (at least) the remote address of at least one partner (and one of the partners needs to be the "master" of the connection, keeping care of it being established).
0
 
Lynchie435Author Commented:
Hi Qlemo,

If I need to send TCP commands to the clients I assume they should be 'listening' to a particular port and then my console application do the send to that port, correct?

Is there any difference with using Terminal Services? Or should all the sessions just listen on the same port irrespective of who they are?

James
0
 
Éric MoreauSenior .Net ConsultantCommented:
0
NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

 
QlemoC++ DeveloperCommented:
Sorry,  didn't read your question thoroughly. I'll need some more information:
1. Is it required to be reliable? I.e. what happens if a message is missed?
2. Is it a broadcast type of message? All form clients receiving the same message?
3. From your last comment, am I correct in deriving that console apps and Forms apps don't run on the same machine?
4. Do you need to keep the messages for some time (logging)?
0
 
melmersCommented:
The most flexible way is a wcf service. You can use on a localmachine only the pipe channels or when you need to separete your tools to different machine swap only the config to tcp and it works. You have a little overhead but i think its less than reading qnd writing all the sql commands
0
 
käµfm³d 👽Commented:
As you can see from the responses above, there are many ways to handle inter-process communication (IPC) in .NET. I'll throw out one more:  pipes. WCF can use these, but you can also use these yourself without the overhead of WCF**. With pipes you basically get a stream object that you can read from and write to. In this way, it's nearly the same as writing a file, so if you have experience with that, then you can easily transition to using a pipe. You can also use pipes across a network, though I believe each end of the pipe has to be .NET (don't quote me on that). (The named pipes can also be used locally if you wan't duplex communication.) Pipes are efficient in terms of memory usage and speed, but I believe that the memory-mapped files are technically faster, ignoring the overhead of initially loading the file into memory.


** Not that there's anything wrong with WCF. WCF is great out of the box. It's great right up until the point that it breaks, and then there's so much going on in the config file that you don't know where to begin looking to fix it.
0
 
Ammar GaffarCommented:
Hi,
I think Message Queuing (MSMQ) is a good option as well, it has an events that you can use rather than timer calls.

But, Qlemo highlighted very important point, you have to consider when deciding your next approach "what happens if a message is missed?"

Good Luck
0
 
Lynchie435Author Commented:
Wow,

Overwhelmed with all the responses here people :)

Thank you very much for all your advice.

It does need to be reliable as it is passing CallID's to the client applications that they then use to 'Pause' and 'Resume' Call Recorders (Basically this is to blank out Credit Card Numbers) based on a focus trigger.

I essentially need to send that CallID to the Client Application and it HAS to get there.
0
 
QlemoC++ DeveloperCommented:
With temporary or permanent logging for surveillance purposes?
0
 
QlemoC++ DeveloperCommented:
And it is time sensitive, as I see it ...
0
 
Lynchie435Author Commented:
Hi Qlemo,

Not really I mean it may help historically however as a Phase 1 I just want to get it out there and efficiently sending the messages from Server Application to Client Application.

There's nothing stopping me putting a non-SQL solution in for this and then tagging on 'SQL Logging' to it at a later date I would assume?

Regards,

James
0
 
QlemoC++ DeveloperCommented:
You can always add logging at any time, but you need to think about which party does the logging - the sender or receiver?

Whatsoever, is there a static relation between Windows client and Caller ID? I.e. does the console application know to whom to send a specific message? Depending on the amount of messages exchanged, it could make a difference to not broadcast all messages to all clients. That said, it is just an implementation detail you can add later, but you should keep it in mind - you want to have each message confirmed, and I would do an active confirmation here (instead of relying on TCP, which applies delays, resends, and some optimization / error recovery procedures). Using UDP is an approach (with manual handshaking and confirming), but that can get complex.
0
 
Lynchie435Author Commented:
Yeah - bear in mind I'm self taught and probably have about 6 months worth of VB.NET experience.

I'm a SQL man myself and have just found myself among VB.NET programming as a requirement by the business to an extent.

I have a feeling presently I am going to have to go with SQL just due to familiarity and the 'unreliability' of TCP which I know enough to do enough being a problem.

I also like the idea of pipes but again is something new that I would have to do some reading up on.

The SQL Database/Tables works I'm just not sure about reliability.

Is there effective way in VB.NET of sending the SQL Insert/Update/Select etc. and making sure that that message is fired off?

Is it as simple as returning the for example an ExecuteNonQuery to a Variable and check the variable (for the number of affected rows) and just not move on in the code until this has been completed?

James
0
 
käµfm³d 👽Commented:
Is it as simple as returning the for example an ExecuteNonQuery to a Variable and check the variable (for the number of affected rows) and just not move on in the code until this has been completed?
IIRC, ExecuteNonQuery returns -1 in all cases. Rather, you would capture and handle the SqlExceptions that are generated.
0
 
Lynchie435Author Commented:
Instead of being lazy I went and looked around.

SqlCommand.ExecuteNonQuery Method

.NET Framework 4.5 Other Versions 29 out of 51 rated this helpful - Rate this topic
Executes a Transact-SQL statement against the connection and returns the number of rows affected.
Namespace:  System.Data.SqlClient
Assembly:  System.Data (in System.Data.dll)

Would wrapping my ExecuteNonQuery Method in a Do Until work?

I.e.

If QryType = "ExecuteNonQuery" Then
                Do Until ReturnVar >= 1
                    ReturnVar = cmd.ExecuteNonQuery()
                Loop
                objConn.Close()
End If

Open in new window

0
 
QlemoC++ DeveloperCommented:
Why should the SQL fail? You can have a) connection issues b) locks c) disk issues d) duplicate key e) ...
so there are really a lot of issues to check for. Simply repeating the same SQL is no solution, you need to check the cause.
0
 
käµfm³d 👽Commented:
Eh, so it would seem. I recall seeing some weird condition where it--or maybe one of the other ExecuteXXX methods--would not return (counter-intuitively) rows affected. Maybe it was the Oracle-equivalent methods.

In any event, I don't think a loop makes sense here. What if there's something wrong on the database itself? You would never know, and your program would be stuck in an (effectively) endless loop. If you get a response back from the database, then your query fired--the result of ExecuteNonQuery tells you whether or not it succeeded or failed. If you get an exception back from ExecuteNonQuery, then your query (possibly) didn't make it to the database.
0
 
Lynchie435Author Commented:
Right OK, bad practice on my part then :)
0
 
QlemoC++ DeveloperCommented:
kaufmed,
ExecuteNonQuery always returns the number of affected rows, AFAIK. For other Execute methods it depends on the type of cursor used if you get -1 (= unknown) or the correct number of rows retrieved.
0
 
käµfm³d 👽Commented:
@Qlemo,

I can't remember the specific scenario where I saw this weird behavior. It's not germane to the issue at hand anyway   = )
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 7
  • 6
  • 4
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now