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?
Related
I am trying to make a program that will listen to if I recieve a E-mail I got a smtp server and so on.
I want to make a database object with Title and text from the Mail and I might want to evolve it into also saving the attacted file to the database so I can use it it my asp.net program.
I think I need a windows Service that will be listening to the email if it gets a email it will add it to datbase and wait again but I am not sure how to do that. if its possible to program that into my asp.net project then it would be a good thing also
Here is a small design on how I was thinking about it
if you know anything about it feel free to come up with any kind of solutions for me.
Read incoming emails with POP3 or Exchange. I've made something similar before, which was a system where users could add links (a type of linking-scam actually) to different websites. So there was a bunch of people in Asia that had a full-time job searching for relevant sites and emailing a list of these URL's to a specific email-address. A service I had running would check the POP3 inbox every 5 minutes or so and then post these links to the website.
You should make an application that gets run at specific intervals rather than a service, which is much simpler. If you're using Azure as a host you can use the scheduled task service there to make a POST call to a page on your site so you don't have to run the code in a different eco-system. Well, I guess you can do that anyway with scheduled tasks in windows.
Here's a POP3 client for .NET
You could make a C# service that checks the pop3 server in a configured interval, and store them in the DB. There's something like this here:
http://aspsnippets.com/Articles/Fetch-and-Read-emails-from-POP3-mail-server-using-C-and-VB.Net---Part-I.aspx
But as a regular application, you just have to make it to run as service (I think you have a project template for that in VS). You have some info here:
http://msdn.microsoft.com/en-us/library/zt39148a(v=vs.110).aspx
Okay I figured out a good solution for this problem friends :)
What I did was I downloaded the EAGetMail and implamentet it. it basicly works for you in a time interval it will check your mail and make a txt file with all the mails so it wont read it again. it also got a aplication field so everytime it runs it will run the selected application.
So I made a console application that runs trough my folder where it will save all my email's as .eml file. It will check for a sub folder called read if its not there then create it and then check the root folder for .eml files read them and save information from it to the database and then move the file to read.
We did not want to use pop3 cuz we wanted the mails to stay intact så we dont lose any information. so we ran for the IMAP4.
and in the asp.net I just run a query that checks the database and use the files.
I am trying to create a simple web email client in C#/ASP.NET. I am trying to use Aspose.Email DLL to connect the to the email server via IMAP and show the emails to the user. Now I am thinking of storing the fetched emails on the filesystem/database or simply fetching and showing these emails on each request.
I think storing email body for all users might increase my database size, but then users would want to page through the results. What is the best strategy to handle emails once fetched via IMAP?
Some regular desktop email clients download emails in advance and store them locally so that they can be displayed more quickly to the user (and for other practical reasons pertaining to search and even navigation, as you mentioned).
Others download the headers only (enough to display a list of emails in a folder) and then download the full body only upon request (when the user opens an email in the list). In the end it's just a tradeoff, and you have to see what works best in your scenario.
Personally I think downloading all emails in a folder at the start is overkill and I've seen clients get stuck for hours downloading emails for particularly large folders. A good option would be to display just enough to show a windowful of information, and get the rest as the user scrolls down - but that's not trivial to implement. Anyhow, the IMAP4 Implementation Recommendations teach you a few tricks to optimise communications with the server and avoid many common pitfalls present in the more popular desktop clients.
If you're worrying about your database growing, you could store only metainformation in the database, and keep the emails themselves on the filesystem (e.g. save them to .eml files). Again, the best solution may vary depending on your particular context.
You can use MailSystem.NET. It is an open-source .NET mail library.
I would like to send a message to an Active Directory user so when he/she loggs in next time they see the message though a popup window. Is it possible to do it in any way beside using the usual netsend?
This is usually a mess when trying to push out a message to a user. If you want a message to pop up, I would suggest that you create a small application with a pull mechanism. When the user logs in, the application should run to determine if they have a message waiting (messages could be in a central database or even file location). If they do, the application could pop up the message. In this way, the application would also bypass most of your firewall/network segment issues. You would only need to open communication to a central location for the data rather than diagnosing network issues for every client.
Not only would this method allow you to do exactly what you are asking for, it would allow you to expand your application to do even more. For example, you could require the user to acknowledge the message in a more formal way than just hitting OK (maybe make them check a box first saying "I read and understand the message"). You could also capture the time when the user saw the message (they might not log in for hours after you send the message). It could also be used when the user is currently logged in and you want to send them a message (the app could poll the server).
While there are downsides to this method (creating an app, installing it everywhere, managing it, etc.) I think the benefits would outweigh the downsides if you really need to have a notification system like you are specifying.
On Windows 2003 you've got an old fashion way of doing that.
In the scriptPath attribut of the AD user nod, you put the name of a script or exe file for example username.cmd.
On your DC, you've got a folder C:\WINDOWS\SYSVOL\sysvol\DOMAIN.NAME\SCRIPTS shared with the name NETLOGON. you just create the file username.cmd in this folder. the program username.cmd is going to be played on every logon of the user. In this file you can put a popup message.
It's still working on Windows Server 2008 R2.
Our application is a Windows client (C++/MFC migrating to C#) that uses SQL Server Express as its data store. We release regular updates to the data the application works with. (Our users use the content data we provide as a basis for their own projects built using the client; the database stores their projects as well, to enable collaboration across a network).
For a while we've used the archaic method of providing huge "update packages" containing all of the latest data. The updater would have to be run on the server, and would swap out the database files with the ones included in the package. Yes, horrible practice for many reasons. We want to do away with it.
Specifically, we will provide an update dialog wherein the user checks off the items they want updated, then clicks Update. A background process then pulls the selected items from the content server and inserts it into the user's database.
What's a secure way to pull this data from inside a Windows client, given that they may opt in or out of potentially hundreds of separate items?
I have considered:
Remote connection to a SQL server. Query for the data directly. Easy to implement, but not secure. Searching for better ways to do this turned up suggestions to use VPN or SSH, neither of which seems particularly convenient for our customers to set up on their client machines.
HTTP content service that provides zip files of each separate content item. Or it builds then dynamically per the user's request. (e.g., we submit an XML file listing the desired items, then a server-side process exports the data from the sql server and zips it up into one package).
How do other apps featuring in-program content updates do it? Any suggestions for heading in the right direction (or at least a good one)?
Thanks,
D
Edit: We aren't necessarily concerned about whether the data transmission is secure (the content is not sensitive data); by "security" in this case I mean "is there a better way than exposing a remote SQL server to slammers in China".
Exposing SQL Server directly is generally a bad idea. Use webservice, WCF instead.
I am scratching my head about this. My scenario are that I need to upload a file to the company server machine(to a folder on c:) from our hosting one(totally different server). I don't know how I should do this. Any of you got tips or code on how this is done.
Thanks Guys
I would set up an FTP server (like the one in IIS or a third-party server) on the Company Server. If security is an issue then you'll want to set up SFTP (secure FTP) rather than vanilla FTP since FTP is not a natively secure transfer protocol. Then create a service on the Hosting Server to pick up the file(s) as they come in and ship them to the company server using C#/.NET's FTP control. Honestly, it should be pretty straightforward.
Update: Reading your question, I am under the strong impression that you will NOT have a web site running on the company server. That is, you do not need a file upload control in your web app (or already know how to implement one given that the control is right in the web page toolbox). Your question, as I understand it, is how to get a file from the web server over to the company server.
Update 2: Added a note about security. Note that this is less of a concern if the servers are on the same subdomain and won't be routed outside of the company network and/or if the data is not sensitive. I didn't think of this at first because I am working a project like this now but our data is not, in any way, sensitive.
Darren Johnstone's File Upload control is as good a solution as you will find anywhere. It has the ability to handle large files without impacting the ASP.NET server memory, and can display file upload progress without requiring a Flash or Silverlight dependency.
http://darrenjohnstone.net/2008/07/15/aspnet-file-upload-module-version-2-beta-1/
There isnt enough info to tell your whole hosting scenario but I have a few suggestions that might get you started in the right direction:
Is your external server owned by another company or group and you cant modify it? If not you might consider hosting the process on the same machine, either in process or as a separate service on the machine. If it cannot be modified, you might consider hosting the service on the destination machine, that way its in the same place as the files need to show up at.
Do the files need to stay in sync with the process? I.e. do they need to be uploaded, moved and verified as a single operation? If not then a separate process is probably the best way to go. The separate process will give you some flexibility, but remember it will be a separate process and a separate set of code to manage and work with
How big is the file(s) that are being uploaded? Do they vary by upload? are the plain files, binaries (zips, executables, etc)? If the files are small you have more options than if they are large. If they are small enough, you can even relay them in line.
Depending on the answers to the above some of these might work for you:
Use MSMQ. This will work for simple messages under about 3MB without too much hassle. Its ideal for messages that can be directly worked with (such as XML).
Use direct HTTP(s) relaying. On the host machine open a HTTP(s) connetion to the destination machine and transfer the file. Again this will work better for smaller files (i.e. only a few KB since it will be done in-line)
If you have access to the host machine, deploy a separate process on the machine which builds or collects the files and uses any of the listed methods to send them to the destination machine.
You can use SCP, FTP (of any form SFTP, etc) on either the host machine (if you have access) or the target machine to host the incoming files and use a batch process to move the files. This will have a lot of issues to address, such as file size, keeping submissions in sync, and timing. I would consider this as a last resort, depending on the situation.
Again depending on message size, you could also use a layer of abstraction such as a DB to act as the intermediate layer between the two machines. This will work as long as the two machines can see the DB (or other storage location) and both act on it. SQL Server Service Broker could be used for this purpose (and most other DB products offer similar products).
You can look at other products like WSO2 ESB or NServiceBus to facilitate messaging between the two apps and do it inline.
Hopefully that will give you some starting points to look into.