I want to start a simple windows P2P instant messenger in C#
I'll put here some questions I need guidance for, in the conceptual and technical aspects.
Let's say the user had successfully logged into his account, and the app needs now to get and populate the list of contacts (saved on my apache/php/mysql server).
How would you implement the data retrieval (important) and later population of the contacts list? Is WebClient.DownloadString[Async] a good approach? Is there a better way?
How often should the app check for updated list (online/offline statuses). Recommendations accepted.
How can I parse JSON data on C#.NET (Visual C# Studio 2010) I will get JSON strings.
Thanks!
You should have user relations in a seperate table that links user ID's. The data retreival should happen through a stored procedure that collects all data for that user on the server and sends them to the user.
You should use the Observer pattern for the update system, then whenever there is a status change you send a message to the user client, that changes the status.
Not sure but I'm pretty sure there is library functionality for this.
Related
I have an application with one DB which is used by many users. Whenever one user makes changes, we save the changes to the database.
Now, I need to notify other logged-in users about this change. How can this be done?
I'm thinking - when the application succcessfully saves / updates the data in the database, the application will send a notification to the connected clients with the new record updated or added.
I'm using C# and SQL Server database.
Your immediate options are push-based notifications with something like a message bus, or polling loops on known ids.
Message busses operate on publish-subscribe models which work well for Windows applications. Have a look at MassTransit or MSMQ as a starting point. There are plenty of options out there. They can be combined into web apps using something that essentially wraps a polling loop with the client like SignalR.
Polling-based options work typically on a timer and do quick timestamp or version # checks against the database, reloading a record if a difference is found.
Push-based are more efficient but only notify of changes between supported applications. (Client to Client) they don't detect changes by applications that don't participate as publishers, nor do they see changes made directly to the database.
Polling-based options cover all changes, but are generally slower and require a schema that has version information to work effectively.
I'm currently working on a requirement that is to "replace the previously developed Polling mechanism for change notifications of database".
Let me elaborate a little:
We have an oracle database where we have put some triggers to get notified for any changes on the table. Using it, we were trying to get changed data and converting it into an XML/Json which is the request-body of an WEBAPI to perform a POST operation in another database.
The new requirement is to skip the polling mechanism and come up with something like "rather than we call the database for notifications, it calls us every time it gets updated".
I did a little googling and everyone suggest for the best approach as:
Database Change Notifications. Here I need to grant permissions to Oracle and then create an application in .Net where I can write a callback function for future processing. Until here, I'm good but my question is:
The .Net application I need to create that communicates with the database is required to be a Web application and has to be online always? Can I create a console application to get notified, if yes, how will the database contact my application for any change? What exactly is the internal process going on when the database notifies my application for any change?
NET Web-forms based application in c#. I need to add a module in the application which allows chatting between logged in users and users can share files during chatting, like Skype. Meanwhile I have to keep a PERMANENT RECORD of each and every word of conversation and files transferred during the session, on my server. I have a bit idea about the implementation of module to achieve the desired result, but I am sure that is not a good practice. Here is my idea:
Chatting:
While users are chatting, create a data-table which will contain the sender id, receiver id, and message contents. When ever user presses send button or hit Enter, a new row would be inserted in the data-table with both IDs and message contents and then the data-table will be bound to a div etc. to show updated messages to both users. At the end, on an event (like window close etc) data-table will be converted to the XML and the XML file will be stored permanently either on hard disk or in database.
File-transfer:
During chatting whenever user press enter/send button we will check the message contents, if the message being sent is a file (with some extension) then upload the file on server and provide a download link to the receiver.
I hope you got my point.
Problem:
1) I want to share files asynchronously i.e. transfer to the receiver and save on the server at the same time. Is it possible?
2) How to tell one user that the other user is typing?
Is there any better way to implement this module? What sort of knowledge should I have to properly comprehend and implement the module?
Thanks for any guidance.
For web-based real-time chat the current open source standard bearer seems to be SignalR.
There are quite a few discussions here on SO about that product and those should help move you in the right direction.
As far as storage is concerned, that will depend upon the infrastructure you have available and the costs you are willing to incur to build the system.
You might look into using RabbitMQ for message delivery and if you set that up appropriately, you can attach queue listeners that will also perform logging of chats as needed. (There are well documented .NET/C# clients already available for RabbitMQ.) You may also want to check out the Wikipedia page for RabbitMQ.
File transfer would probably be best done through uploading of the file to the web-server and temporary storage there with a link to the file to be downloaded by the other chat client. That causes the server to increase its bandwidth requirements though.
You might also look into running your own XMPP server and using a web interface through SignalR to interface into the XMPP server. It might leverage the most functionality for easing time to market.
Have you looked into SignalR?
Greetings!
I'm needing to deploy a compact database with an application I am working on. The database acts as a cache for data the app has already seen, and that data will never change, so the cached values will never become outdated. I've chosen SQLite, and I'm writing in C#.
I'd like to protect the database files so they cannot be easily accessed or edited by the user - keeping access to my application only. Now, one option is to use password protection which is fine except that with tools like Reflector one could easily view a near original version of the source and check the passwords/how they are generated per file and replicate this.
Are there any suggestions on how to achieve this result or something close? Have people done something like this in the past?
Thanks!
Security by obscurity.
If your apps can decrypt it, then your user can do it too.
If you want to keep it secure, you'll have to keep it for yourself. Your best bet is to store the database on a server and make it available via a web service. Perform access control checks on your own server so that the application can only access the parts of the database it has to see.
I don't have a clearcut answer for you (obfuscate your code during release deployment, make the password obscenely long) as the golden rule stands: If they have physical access to the executable (substitute machine/car/door) they can get in if they want(and have skills).
All you can do is make things difficult for them.
This area is not my forte, but one thing I could suggest is to just think about what data you are actually sending and determine if there is any way that you can limit any of the more sensitive data from being transmitted to the client in the first place.
If your concern is over sending things like ID numbers account numbers to the client, then perhaps you could translate those values into a client-only version that is meaningless outside of your application. Your server could have a table that contains the translation between the real values and the client-only values.
Let's say you have this table stored in your server's database (not the client database!)
RealAccountNumber ClientOnlyAccountNumber
981723 ABC123
129847 BCD234
923857 CDE345
...
So the client only sees the account numbers in the ClientOnlyAccountNumber column, and when a client sends a request to the server for an action to be performed on account "ABC123", the server knows to translate that into account number 981723.
I will try and explain exactly what I want to achieve first.
Imagine two users are using a windows forms application, when User A opens a particular form a lock is applied to the data record underlying the form so that only that user can make changes at that time.
User B has a list of all records (in a grid) which among others contains a reference to the record already opened by User A. What we want to do is when User A opens the records User B's list of records is updated to show a lock icon next to the row to indicate the record is in use.
This is a trivial example of what we do with messaging but you get the idea, User A does something User B needs to knows about it.
I have implemented a system using Jabber-net for C# and an OpenFire Jabber Server. Basically when a message is to be sent, a new row gets inserted on a messages table in the database. The messages table is watched by a service client using the SqlDependancy object, so that when a new message is ready the service builds the relevant message and sends it to the desired client via Jabber and the OpenFire server.
This works OK, however OpenFire's out of the box functionality is for supporting Instant Messaging which obviously isn't what I'm trying to achieve . The problem I have is that if a user is logged in to two Application Contexts (i.e. Test and Live) OpenFire does not know which one to send a message to because the JID structure of user#server/resource takes no notice of the resource.
Basically the way I'm currently using OpenFire and Jabber-net isn't quite right.
Is there a pattern I can use for achieving what I want to achieve i.e. send a message to a client telling it do something, whilst being able to specify which client you are sending the message too. XMPP seemed like the answer because I can construct my own messages types to be parsed.
My application is a Windows Forms, .NET 3.5 C# application.
I'd just add some more data to indicate which Application Context is affected and have the other clients decide whether they need to handle the message or not.