"Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> wrote in
news:449c2ba0$1@newsgroups.borland.com:
>
> "m utku karatas" <m.utku.k@g_o_o_g_l_e_smailservice.com> wrote in
> message news:Xns97EB92AF338063n523m3@207.105.83.66...
>
>> I keep the code a little abstracted so at some point I can
>> switch to other IPC technics.
>
> Indy's architecture is pluggable, in that you can write your own
> custom IOHandler classes for your own IPC systems, and then the same
> Indy code will still work.
Will consider this, thanks.
>> I wish it was. The interesting thing is that while client's(C++ one)
>> Send call is blocked, the server is also blocked in the ReadCardinal
>> func.
>
> The only way that can happen is if the client is not sending any data
> to begin with. Or is not sending enough data. Cardinal is usually 32
> bits, but can change depending in the platform. Well, so can Integer,
> for that matter, I guess. Make sure the client is actually sending
> what the server is expecting. You might also consider using a packet
> sniffer, such as Ethereal, to make sure data is actually passing
> through the network connection correctly.
>
>> Not asking the coding way, I meant a tool like Ethereal hooking
>> directly windows' connection. Any recommendation on that?
>
> You just answered your own question - use Ethereal. Or did you have
> something else in mind? Please be more specific when you ask
> questions.
Ethereal shows the flow in the connection AFAIK, what I wondered was if
there is a tool showing the actual TCP buffer(logging what's in it
currently) of the operating system, in my case winXP.
>
>
> Gambit
>
>
--
Best regards.
M. Utku Karatas
