|
Hi karam chandra,
Finally i got the book from here.
It's free.
If u find useful.
regards,
Divyang Mithaiwala
Software Engineer
|
|
|
|
|
Hello,
I'm developing an application to capture and copy POP3 email then send
it to an email server. I need to do this before the traffic gets to the
user's email client application. In my investigation so far, it looks like my
options are to do this at the Winsock layer (with potential performance
implications), or in a kernel mode NDIS driver. I'm leaning to the latter
solution (perhaps by utilizing WinPcap).
Any advice or pointers to other resources would be appreciated.
Thanks.
Ken....
|
|
|
|
|
Ken,
This type of application would have to sit before or on the PoP3 Server in question to work as you may be aware of.
If PoP3 is using any type of encryption between other hops, then you may not be able to see anything but the IP header of any of the packets. This also goes for what type of encoding is being used on the data packets from the headers.
Definately using a NDIS driver will do the trick. Or a simplified way is to proxy the PoP3 Server if you have admin access to that server.
An example would be to change the port of the PoP3 server to 111. Your program would listen on port 110. This would allow you to do any pre-processing on any of the information coming in, then connect to the PoP3 on 111 and handoff what you need to passthrough.
You can readup on the Pop3 protocol at the W3C (World Wide Web Consorium).
If you cannot get access to the server, then accomplishing this can only be done at the packet level.
Hope this helps!
~ CodeDoctor ~
|
|
|
|
|
Thanks for the response. What I ended up doing was basically writing an email client to read the email from the server, instead of capturing the email as it goes up the stack to the user's email client. This approach solved alot of issues, including some you mentioned.
Ken....
|
|
|
|
|
I have a multi-level composite that I need to build. The composite is a classic composite pattern. Each level of the composite is a different concrete class that implements the same component interface. There is a one-to-many at each level. The objects at different levels of the composite are created based on data read from a database. I was considering using Builder to build the composite structure, but it seems that the director code would be too involved to do that. The director method that interfaces to the builder would have to have have a nested loop for each level in the composite (e.g., build these, now for each one of them, add these, now for each one of them, add these...). In addition, if I wanted to add or remove a layer, I would have to modify the director method that interfaces to the builder. My question is how can you use Builder and keep the director from becoming a huge nested loop that directs the building of each level of the composite?
-- modified at 13:13 Friday 5th January, 2007
|
|
|
|
|
Lockheed Bob wrote: The objects at different levels of the composite are created based on data read from a database.
Doesn't the data contain the nesting relationships?
led mike
|
|
|
|
|
I have the following situation:
I have an app that lives on an application server that will only be accessed via Terminal Services. Multiple users will be able to run this application. The actions of one user will affect the ability of other users to perform certain actions in their instance of the application.
Due to the nature of the application and file/registry access limitations of said server, I figure a service could be used as a marshal to implement that idea. The idea is that each user's app instance could communicate with the service to set/get access toggles (just two integers representing the object to be accessed, and a 1/0 toggle indicating whether or not access should be granted).
My questions are:
1) Can apps being run by multiple users via terminal services all access the service on the server? (I can't think of any reason they shouldn't be able to). If the answer to this is no, ignore the next few questions.
2) How do I find out if the service is even loaded from the application?
3) How would I exchange data with the service?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Seems to me there are a number of Windows-provided mechanisms you can use to synchronize access to things between intances of your application: events, timers, mutexes or semaphores.
As for how you could do interprocess communication, there're Named Pipes, sockets, or COM.
Ken....
|
|
|
|
|
I would choose either sockets or Pipes (pipes if you are not too good with sockets like me )
Actually once i worked on a service that watched a particular directory for command files (simple XML files) and performed the action specified in those XML files (works well if we only have one way communication), pretty lousy mechanism but worked beautifully through network shares
If you think you can than you can, if you think you can't you are right.
|
|
|
|
|
John Simmons / outlaw programmer wrote: 3) How would I exchange data with the service?
If both the service and the app are .NET you might look at using .NET Remoting.
led mike
|
|
|
|
|
Named pipes would probably be the easiest, or RPC/DCOM/Remoting, but sharing memory through mapped files and syncronizing with a mutex would have the best performance.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you.
-Chris Maunder
|
|
|
|
|
I am designing a *windows forms* application that displays data in a DataGridView.
The data is tabular, with about 12 columns, and with thousands of records.
The DataGridView data will be changed programmatically but it also can be changed by the user.
I want to be able to *locally persist* the DataGridView data from run to run; i.e., the PC may never connect to a remote database or may only occasionally connect.
I want to be able to programmatically delete old records to keep a ceiling on the number of records that share a thread ID.
My thoughts on where to locally persist the data are:
● INI file
● Windows Registry
● XML file
● Microsoft Access or other database
My thoughts on these:
● The INI file seems to be a nightmare to work with.
● The Windows Registry would be off-limits for some users and would probably quickly max out.
● The XML file seems to be favored in web forms rather than windows forms. Many XML controls and classes are in System.Web, which doesn't seem to be available in web forms.
● Microsoft Access probably would be cost-prohibitive, most of my users do not currently have it, its initial use of disk space seems to be high, and it can become bloated and need to be compacted. On the good side, having indexes and running SQL queries are both great. Maybe another database system would work if it has a small footprint, is easy to install, etc.
I'm hoping that someone can suggest a better option, give me some guidance, or give me a link to an implementation or example.
- Vkleo
|
|
|
|
|
Have a look at Smart Clients. This disconnected state is what they are designed for.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Thanks for your suggestion Pete. I looked into Smart Clients and I see that they are the type of application I am designing, but they do not really specify a good way to pull off the local persistence of data. They just state that it would be cached, or would use a local database, but then give no further specifics. That leads me back to the initial thoughts on using XML or some (currently unknown to me) free database that's easy to install and hook up. I did find the topic of WinFS intriguing, but I was left with the impression that that would only have widespread availability years in the future.
- Vkleo
|
|
|
|
|
Try the Smart Client Offline Application Block[^].
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Thanks for the link Pete!
Pete O`Hanlon wrote: Try the Smart Client Offline Application Block[^].
That document led me to find "SQL Server Compact Edition", whose final release is expected this month. It's compact and allows SQL. I think it's free.
I believe the document is going to be an excellent guide for me going forward.
Thanks again!
- Vkleo
|
|
|
|
|
If you're using a DataSource as (no pun intended) the data source to the DataGridView then any can't you use the DataSource.WriteXml and DataSource.ReadXml routines?
The controls then don't care whether they're bound to an SQL database or an (in this case) an xml file.
vkleo wrote: Many XML controls and classes are in System.Web, which doesn't seem to be available in web forms.
Can you explain this a bit futher?
I have no idea what I just said. But my intentions were sincere.
|
|
|
|
|
Ed, I misspoke in my initial post, so let me explain what I meant to say. What I should have said was that the web forms toolbox contains controls like XML and XMLDataSource but the windows forms toolbox does not contain any obvious XML controls. I was thinking that web forms had more XML capabilities than windows forms, but it looks to me like windows forms will have sufficient XML capabilities for my needs.
My windows form now has a DataGridView , whose data source is a BindingSource (auto-created by Visual Studio), whose data source is a DataSet . During Form_Load I use DataSet.ReadXml and I'll use DataSet.WriteXml whenever I want to save.
I see that the DataSet creates its own "XML Schema", so I discarded my original hand-coded "XML Schema".
One of my technical advisors told me that he worked at a place that used XML files and used XSLT to query/filter the XML data. I could query/filter the XML data the same way, or maybe instead query/filter the data in the DataGridView . At first glance I would prefer not to access the data in the DataGridView but I'll need to think for a little while about the trade-offs between these two ways.
Thanks for the hint Ed!
- Vkleo
|
|
|
|
|
vkleo wrote: I could query/filter the XML data the same way, or maybe instead query/filter the data in the DataGridView.
No need to do either I think. If you want to create different views that's what the DataView component's for, if you insert this into the "chain" between the DataSource and the binding source then you can write regular SQL statements to filter / query the data.
The datasource will also allow to you query the data using SQL if you want as well.
(As far as I knew anyway the ASP binding way of things is waaaaayy behind the Windows.Forms way of doing things (even for Xml), just because they have Xml in their title doesn't mean their better. The only downside I suppose is that the WinForms versions do everything so aren't that lean and mean).
I have no idea what I just said. But my intentions were sincere.
|
|
|
|
|
Ed, I read up on the DataView and it certainly seems to be a better than the other 2 choices.
Ed.Poore wrote: [With] the DataView component... you can write regular SQL statements to filter / query the data.
Ed.Poore wrote: The datasource will also allow to you query the data using SQL if you want as well.
How would I run an SQL statement against the data? I didn't notice a method in either the DataView or the DataSet (i.e., the specific type of datasource that I populate using DataSet.ReadXml ) that allows me to use SQL. Can you show me a trivial line or two of code for each of these two classes?
- Vkleo
|
|
|
|
|
It's not exactly an SQL statement, but SQL syntax:
dataView.RowFilter = @"Country='UnitedKingdom' AND Surname='Poore'";
I have no idea what I just said. But my intentions were sincere.
|
|
|
|
|
Quite often, I have had to work (read fix here) with other people's database developments where they implement separate insert/update methods in the business layer.
A lot of the time, this doesn't actually make sense, and it is nicer just to provide a Save method where the save itself works out whether or not it needs to insert or update the record. As an example, consider the following Stored Procedure:
CREATE PROCEDURE [MyUser].[SaveUser]
@ID INT OUT,
@UserName NVARCHAR(30)
AS
SET NOCOUNT ON
IF @ID = 0
BEGIN
INSERT INTO UserDetails(ID, Name) VALUES (@ID, @UserName)
SET @ID = SCOPE_IDENTITY
END
ELSE
BEGIN
UPDATE UserDetails SET Name = @UserName WHERE ID = @ID
END
This means that the datalayer just needs to call the SaveUser procedure and the SP will work out whether it needs to do a save or an insert. Now, there are some arguments as to whether or not this is the responsibility of the datalayer, but look at how this simplifies procedure development. Instead of having Insert/Update/Delete, you end up having Save/Delete, thus simplifying your datalayer. The downside here is that you have to check the @ID field first, which is a (minor) performance hit that you may want to forego.
Alternatively, you could have the datalayer implement the same logic and determine whether or not this is an insert by checking the ID field beforehand.
public void Save()
{
if (_id == 0)
{
}
else
{
}
}
All I am asking, is that you remove the decision as to whether to insert or update from the business layer. Please...
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: Alternatively, you could have the datalayer implement the same logic and determine whether or not this is an insert by checking the ID field beforehand.
Or Alternatively you could let the data adapter do its job and make exactly the same decision for you.
Notice that the Data Adapter has only 2 main methods:
Fill - Executes your Select
Update - Executes your Insert,Update or Delete depending on the current state of the row being saved.
Sorry to say I 100% disagree with your oppinion that proper CRUD stored procedures are not a good thing.
|
|
|
|
|
J4amieC wrote: Or Alternatively you could let the data adapter do its job and make exactly the same decision for you.
Notice that the Data Adapter has only 2 main methods:
Fill - Executes your Select
Update - Executes your Insert,Update or Delete depending on the current state of the row being saved.
This only works if you are using a Data Adapter. In most cases, I have been dealing with more traditional business objects that are mapped into the database. For instance, having a Customer class and a Customers collection with the Customers collection being responsible for returning a number of populated Customer classes.
J4amieC wrote: Sorry to say I 100% disagree with your oppinion that proper CRUD stored procedures are not a good thing.
Where in my original post did I state that CRUD procedures are not a good thing? I present a couple of alternatives for saving data - one which uses a composite INSERT/UPDATE procedure, and the other which uses C# code to accomplish the same thing. What I did state was that it shouldn't be the responsibility of the business layer to work out whether to do an insert or an update. My last line was the important one:
All I am asking, is that you remove the decision as to whether to insert or update from the business layer. Please...
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Pete O`Hanlon wrote: All I am asking, is that you remove the decision as to whether to insert or update from the business layer.
I agree and infact when I do use SPs I try and do this, makes the client code simpler and that's more likely to change so why make more work?
I have no idea what I just said. But my intentions were sincere.
|
|
|
|