You can easily disable screen updates and replace it by log file.
Ethereal is not always able to catch trafic on localhost.

--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be


----- Original Message ----- 
From: "Fastream Technologies" <[EMAIL PROTECTED]>
To: "ICS support mailing" <[email protected]>
Sent: Friday, July 28, 2006 6:19 PM
Subject: Re: [twsocket] Very strange problem with server 
andclientsoftware...


> SocketSpy sometimes has side-eefects when speed is the main changing
> parameter! It slows down connections due to slow screen update. I would
> suggest www.ethereal.org.
>
> FYI.
>
> SZ
>
> ----- Original Message ----- 
> From: "Francois PIETTE" <[EMAIL PROTECTED]>
> To: "ICS support mailing" <[email protected]>
> Sent: Friday, July 28, 2006 7:01 PM
> Subject: Re: [twsocket] Very strange problem with server and
> clientsoftware...
>
>
>>> for some unknown reason.  I have never seen a scenario where the 
>>> programs
>>> run fine from different machines, but won't work on the same machine.  I
>>> am
>>> really hoping someone might have seen something similar?  Could it be a
>>> WinSock bug?
>>
>> I don't think it is a winsock bug.
>> The main difference between running programs on different machine and on
>> the
>> same machine is the speed. On the local machine, it is likely to be very
>> fast. You have to pay attention to your DataAvailable event handler so
>> that
>> it doesn't care how data is split into packets.
>>
>> I suggest you use SocketSPY (see usermade page at ICS website) to spy on
>> the
>> communication between your programs, either when running on different
>> computers or running on the same computer. You may modify SocketSpy
>> slightly
>> to log all traffic to a file foe later analysis and comparing running the
>> program locally or remotely.
>>
>>
>> --
>> Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
>> --
>> [EMAIL PROTECTED]
>> http://www.overbyte.be
>>
>>
>>
>> ----- Original Message ----- 
>> From: "Hoby Smith" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Friday, July 28, 2006 5:46 PM
>> Subject: [twsocket] Very strange problem with server and client
>> software...
>>
>>
>>> Hello.  I am experiencing some very strange symptoms with some programs
>>> that
>>> communicate using ICS.
>>>
>>>
>>>
>>> Summary: The programs communicate fine (stable and consistent) when they
>>> are
>>> run on DIFFERENT machines.  However, when run on the SAME machine, the
>>> communication between the programs is very unpredictable (sporadic
>>> failures,
>>> varying in frequency).  In contrast to this, there are CERTAIN machines,
>>> where they DO run fine (stable and consistent) on the same machine.
>>> Oddly
>>> the working machines have Delphi installed on them and the failing
>>> machines
>>> do NOT have Delphi installed on them (which shouldn't matter).
>>>
>>>
>>>
>>> Detail: (sorry so long)
>>>
>>>
>>>
>>> I have implemented a thin client architecture using a basic Server /
>>> Client
>>> pattern.  Meaning, there are two programs; one functions as a Server
>>> (actually a Broker) using TWSocketServer and another Client program uses
>>> TWSocket.  The Client program initiates the connection and generates TCP
>>> traffic of a varying nature, depending upon specific user activities.
>>> The
>>> sessions are persistent (the client stays connected for the life of the
>>> application).  The session traffic uses my own packetized protocol,
>>> something I have done many times (including with ICS).
>>>
>>>
>>>
>>> The Server uses a single TWSocketServer on the Main Form for all
>>> communications, meaning no Server based threads for TCP handling.
>>> However,
>>> while processing inbound packets from the Client program, it does hand
>>> some
>>> chores off to a thread pool that does the mundane chores (DB lookups,
>>> etc).
>>> A thread may or may not send one or more packets to the client, 
>>> depending
>>> upon the particular protocol chore they were handling (requesting data 
>>> of
>>> different types, reporting on Client interface activities, etc).  The
>>> Server's outbound packet calls via the TWSocketClients all funnel 
>>> through
>>> one critical section, which should provide thread safety for outbound
>>> traffic.
>>>
>>>
>>>
>>> There are a few other items that may worth noting.
>>>
>>>
>>>
>>> There is an additional load balancing program (Router) that is not
>>> directly
>>> engaged in the session.  The Client first connects to the Router, which
>>> provides Server connection information to the Client.  The Client
>>> disconnects from the Router and re-connects to the directed Server.
>>> There
>>> is an Admin channel between the Router and Server (Broker) that provides
>>> intelligent load balancing info, which OBVIOUSLY uses a SEPARATE socket
>>> interface, distinct from Client / Server channel.
>>>
>>>
>>>
>>> Additionally, this all occurs on top of my own Secure Channel
>>> implementation, which uses bi-directional BlowFish encryptors and
>>> multiple
>>> private keys to seed various encryption and randomizing algorithms.
>>>
>>>
>>>
>>> Also, I am using a MySQL Database via the MicroOLAP MySQLDAC components,
>>> which MicroOLAP claims is thread safe and appears generally to be.
>>>
>>>
>>>
>>> Oddly, the Client and Server programs work fine when both are running on
>>> my
>>> 2 development machines.  (As a result, I didn't catch this issue until
>>> later
>>> in development, like before a demo. :-( ).  However, when I try to run
>>> both
>>> of them on any other machine (so far), they communicate very poorly.
>>> Basically, they experience symptoms of random packet drops, but I don't
>>> think that is actually the case.  I can't really tell, because I can not
>>> reproduce the scenario on a development machine where I could trace and
>>> debug the issue.  The session will just hang, usually during the
>>> handshaking
>>> stage (Channel setup), but not always.
>>>
>>>
>>>
>>> However, if the Server and Client are on DIFFERENT machines, they work
>>> wonderfully, no problems at all, no matter what MACHINES they are on.
>>>
>>>
>>>
>>> I have tried a BUNCH of things to attempt to isolate and / or alleviate
>>> the
>>> problem.  I have changed the Threading property on the Server Socket,
>>> which
>>> seems to have no effect.  I have also tried using local MySQL Server vs.
>>> Remote MySQL server, no effect either way.  As well as a many other 
>>> tests
>>> /
>>> solutions.  All to no avail.
>>>
>>>
>>>
>>> I am stumped in a big way.  I understand that this is a really
>>> complicated
>>> implementation and my issue could be caused by a NUMBER of things.
>>> However,
>>> most of my testing seems to isolate the issue to the communications
>>> layer,
>>> for some unknown reason.  I have never seen a scenario where the 
>>> programs
>>> run fine from different machines, but won't work on the same machine.  I
>>> am
>>> really hoping someone might have seen something similar?  Could it be a
>>> WinSock bug?
>>>
>>>
>>>
>>> Any help would be appreciated.
>>>
>>>
>>>
>>> Thanks much.
>>>
>>>
>>>
>>> Hoby
>>>
>>> -- 
>>> To unsubscribe or change your settings for TWSocket mailing list
>>> please goto http://www.elists.org/mailman/listinfo/twsocket
>>> Visit our website at http://www.overbyte.be
>>
>> -- 
>> To unsubscribe or change your settings for TWSocket mailing list
>> please goto http://www.elists.org/mailman/listinfo/twsocket
>> Visit our website at http://www.overbyte.be
>
> -- 
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be 

-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to