From: Thomas F. Divine [tdivine@pcausa.com]
Sent: Thursday, October 26, 2000 11:41 AM
To: NT Developers Interest List
Subject: [ntdev] Re: TDI Question

I haven't noted the problem that you mention. Perhaps you can give an
example situation where you observe it.

On the other hand, note that the context that I lookup for event handlers is
neither the address object nor the connection context. It is the (possibly)
arbirtary context that was specified when the event handler was set on the
address object.

Sorry I can't be of more help.

Thomas

----- Original Message -----
From: justin white <justin@justinmarkwhite.com>
To: NT Developers Interest List <ntdev@lists.osr.com>
Sent: Thursday, October 26, 2000 11:35 AM
Subject: [ntdev] Re: TDI Question


> Thanks,
>  I have found that the TDI filtering is quite messy. I also save the
original address object in my event handler and so can easily get to it when
my event is called. Unfortunately the ConnectionContext receive in the call
does not correlate to any other context I 'see' previously (like from a
TDI_CONNECT for instance). This also leads to my next question, why is
TDI_ASSOCIATE_ADDRESS not always called. According to the TDI spec, it
should be called.
>
> On Thu, 26 October 2000, "Thomas F. Divine" wrote:
>
> >
> > Justin,
> >
> > Unfortunately, filtering TDI is fairly messy. In addition, there are no
> > standard reference samples that we can talk to. PCAUSA licenses some,
but
> > that doesn't help you.
> >
> > From reading your previous messages it appears that at least one of your
> > problems seems to be how to relate the ConnectionContext in an Event
> > callback to something meaningful.
> >
> > The steps that work for us include:
> >
> > 1.) Filter creation of address objects. Create a structure in the TDI
filter
> > to track each created address object.
> > 2.) Filter SetEvent calls on each address object. In this filter we save
the
> > original caller's EventHandler and EventContext and replace both with
our
> > own proxies. This info is saved in our address object tracking
structure.
> > 3.) When an event callback is made it goes to our hook. There we lookup
our
> > proxy EventContext to find the unfiltered EventContext, the unfiltered
> > EventHandler and, or course, the address object.
> >
> > Hope this helps a little.
> >
> > Regards,
> >
> > Thomas F. Divine
> >
> > PCAUSA - Toolkits & Resources For Network Software Developers
> > NDIS Protocol - TDI Client - Windows 95 Redirector
> > <http://www.pcausa.com>
> >
> > ----- Original Message -----
> > From: justin white <justin@justinmarkwhite.com>
> > To: NT Developers Interest List <ntdev@lists.osr.com>
> > Sent: Thursday, October 26, 2000 3:39 AM
> > Subject: [ntdev] TDI Question
> >
> >
> > > Hi All,
> > >
> > > Please can someone give me some information on how to associate the
> > Address File Object and the Connection Endpoint file Object, which are
> > created when a connection is requested at the TDI layer. I am not
building a
> > snoop or anything of the sort but need to be able to intercept data at
the
> > tdi level.
> > >
> > > your help would really be appreciated.
> > >
> > > Thanks
> > > Justin
> > >
> >
> >
> >
> >
> > ---
> > You are currently subscribed to ntdev as:
justinmarkwhite.com@namezero.com
> > To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com
>
>
> _______________________________________
> Click here to get your free domain name
> and personal portal from NAMEzero(TM):
> http://www.namezero.com
>
> ---
> You are currently subscribed to ntdev as: tdivine@pcausa.com
> To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com
>


---
You are currently subscribed to ntdev as: GlennEverhart@FirstUSA.com
To unsubscribe send a blank email to leave-ntdev-247T@lists.osr.com