Re: [twsocket] When does OnSessionAvailable event fire
Ah. I see. Thank you. Before I posted my question I read as much
information on all this as I could including my old postings from last year
and the wsocket.hlp file. As I understand it then, the Wsocket.hlp file is
wrong or even worse, vague giving the impression that something is possible
when it really isn't.
Applies to
TWSocket
Declaration
Function Listen: Integer;
Description
The listen method is used to build a server application where a given socket
must wait for incomming remote connections. The listen method ask the
underlaying level to wait for connection. It is non blocking: listen returns
immediately whitout waiting for an actual connection. When a connection will
be available at a later time when the client connected, the
OnSessionAvailable event will be generated. The OnSessionAvailable event
handler will normally call the accept method to retreive the client
connection handle.
Before calling the listen method, you must properly setup the Addr, Port and
Proto properties.
The example that follows in the .hlp file uses telnet not tcp or udp.
Perhaps an extra statement in the wsocket.hlp file that this does _not_
apply to UDP and that listen does not ever generate a call to
OnSessionAvailable would have saved me some time.
Cheers,
John Dammeyer
Wireless CAN with the CANRF module now available.
http://www.autoartisans.com/products
Automation Artisans Inc.
Ph. 1 250 544 4950
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Francois PIETTE
> Sent: Saturday, June 10, 2006 11:20 AM
> To: ICS support mailing
> Subject: Re: [twsocket] When does OnSessionAvailable event fire
>
>
> > I think I'm missing something critical but can't quite
> figure it out.
>
> Your are missing the fact that you use UDP and not TCP. UDP is
> connectionless and sessionless. So don't use TWSocketServer.
> Use TWSocket,
> make it listen and the just handle OnDataAvailable event to
> call Receive to
> get the incomming datagrams.
> Have a look at the document "TCP/UDP primer" available from
> support page at
> my website.
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
>
>
> - Original Message -
> From: "John Dammeyer" <[EMAIL PROTECTED]>
> To: "'ICS support mailing'"
> Sent: Saturday, June 10, 2006 8:04 PM
> Subject: [twsocket] When does OnSessionAvailable event fire
>
>
> > Hi,
> >
> > I've finally been able to restart a project from last
> October. Something
> > has gone missing and code that used to work doesn't
> anymore. So I have to
> > sort of start over. I've followed the example code, looked
> at my postings
> > from back then in the archives but I'm having problems with
> the following
> > sequence.
> >
> >
> > On FormShow I execute the following code:
> >
> >if FirstTime then begin
> >SrvSocket.Proto := 'udp';
> >SrvSocket.Addr:= '127.0.0.1';// Use loopback
> >SrvSocket.Port:= PortEdit.Text;// Wait on
> this port (4000).
> >SrvSocket.Listen; // Start
> listening for
> > client
> > which also fires
> > //
> > OnSessionConnected.
> > FirstTime := FALSE;
> >PortEdit.Enabled := FALSE;
> >end;
> >
> > As per the example in the FAQ I want to run this method when
> > 'OnSessionAvailable' fires but it never happens. What's
> needed to make
> > this
> > event fire? Running a client on that port (4000) doesn't seem to do
> > anything while sending UDP messages to that port from a
> client app does
> > get
> > through.
> >
> > I think I'm missing something critical but can't quite
> figure it out.
> >
> > Thanks
> >
> > John Dammeyer
> >
> > procedure TForm1.SrvSocketSessionAvailable(Sender: TObject;
> ErrCode:
> > Word);
> > var
> >NewHSocket : TSocket;
> >PeerName : TSockAddrIn;
> >Peer : String;
> > begin
> >PortEdit.Enabled := TRUE;
> >{ We need to accept the client connection }
> >NewHSocket := SrvSocket.Accept;
> >
> >{ And then associate this connection with our client socket }
> >CliSocket.Dup(NewHSocket);
> >
> >{ Wants to know who is connected to display on screen }
> >CliSocket.GetPeerName(PeerName, Sizeof(PeerName));
> >
> >{ User likes to see internet address in dot notation }
> >Peer := IntToStr(ord(PeerName.sin_addr.S_un_b.s_b1)) + '.' +
> >IntToStr(ord(PeerName.sin_addr.S_un_b.s_b2)) + '.' +
> >IntToStr(ord(PeerName.sin_addr.S_un_b.s_b3)) + '.' +
> >IntToStr(ord(PeerName.sin_addr.S_un_b.s_b4));
> >InfoLabel.Caption := 'Remote ' + Peer +
> > ' connected. Port:' + CliSocket.GetPeerPort;
> >
> >{ Send a welcome message to the client }
> >//CliSocket.SendStr('Hello' + #13 + #10);
> >
> >{ Enable the server user to disconect the client }
> >DisconnectButton.Enabled := TRUE;
> >InitDisplayButton.Enabled := TRUE;
> > end;
> >
> > --
> > To unsubscribe or change your set
Re: [twsocket] When does OnSessionAvailable event fire
> I think I'm missing something critical but can't quite figure it out.
Your are missing the fact that you use UDP and not TCP. UDP is
connectionless and sessionless. So don't use TWSocketServer. Use TWSocket,
make it listen and the just handle OnDataAvailable event to call Receive to
get the incomming datagrams.
Have a look at the document "TCP/UDP primer" available from support page at
my website.
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "John Dammeyer" <[EMAIL PROTECTED]>
To: "'ICS support mailing'"
Sent: Saturday, June 10, 2006 8:04 PM
Subject: [twsocket] When does OnSessionAvailable event fire
> Hi,
>
> I've finally been able to restart a project from last October. Something
> has gone missing and code that used to work doesn't anymore. So I have to
> sort of start over. I've followed the example code, looked at my postings
> from back then in the archives but I'm having problems with the following
> sequence.
>
>
> On FormShow I execute the following code:
>
>if FirstTime then begin
>SrvSocket.Proto := 'udp';
>SrvSocket.Addr:= '127.0.0.1';// Use loopback
>SrvSocket.Port:= PortEdit.Text;// Wait on this port (4000).
>SrvSocket.Listen; // Start listening for
> client
> which also fires
> //
> OnSessionConnected.
> FirstTime := FALSE;
>PortEdit.Enabled := FALSE;
>end;
>
> As per the example in the FAQ I want to run this method when
> 'OnSessionAvailable' fires but it never happens. What's needed to make
> this
> event fire? Running a client on that port (4000) doesn't seem to do
> anything while sending UDP messages to that port from a client app does
> get
> through.
>
> I think I'm missing something critical but can't quite figure it out.
>
> Thanks
>
> John Dammeyer
>
> procedure TForm1.SrvSocketSessionAvailable(Sender: TObject; ErrCode:
> Word);
> var
>NewHSocket : TSocket;
>PeerName : TSockAddrIn;
>Peer : String;
> begin
>PortEdit.Enabled := TRUE;
>{ We need to accept the client connection }
>NewHSocket := SrvSocket.Accept;
>
>{ And then associate this connection with our client socket }
>CliSocket.Dup(NewHSocket);
>
>{ Wants to know who is connected to display on screen }
>CliSocket.GetPeerName(PeerName, Sizeof(PeerName));
>
>{ User likes to see internet address in dot notation }
>Peer := IntToStr(ord(PeerName.sin_addr.S_un_b.s_b1)) + '.' +
>IntToStr(ord(PeerName.sin_addr.S_un_b.s_b2)) + '.' +
>IntToStr(ord(PeerName.sin_addr.S_un_b.s_b3)) + '.' +
>IntToStr(ord(PeerName.sin_addr.S_un_b.s_b4));
>InfoLabel.Caption := 'Remote ' + Peer +
> ' connected. Port:' + CliSocket.GetPeerPort;
>
>{ Send a welcome message to the client }
>//CliSocket.SendStr('Hello' + #13 + #10);
>
>{ Enable the server user to disconect the client }
>DisconnectButton.Enabled := TRUE;
>InitDisplayButton.Enabled := TRUE;
> end;
>
> --
> 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
[twsocket] When does OnSessionAvailable event fire
Hi,
I've finally been able to restart a project from last October. Something
has gone missing and code that used to work doesn't anymore. So I have to
sort of start over. I've followed the example code, looked at my postings
from back then in the archives but I'm having problems with the following
sequence.
On FormShow I execute the following code:
if FirstTime then begin
SrvSocket.Proto := 'udp';
SrvSocket.Addr:= '127.0.0.1';// Use loopback
SrvSocket.Port:= PortEdit.Text;// Wait on this port (4000).
SrvSocket.Listen; // Start listening for client
which also fires
//
OnSessionConnected.
FirstTime := FALSE;
PortEdit.Enabled := FALSE;
end;
As per the example in the FAQ I want to run this method when
'OnSessionAvailable' fires but it never happens. What's needed to make this
event fire? Running a client on that port (4000) doesn't seem to do
anything while sending UDP messages to that port from a client app does get
through.
I think I'm missing something critical but can't quite figure it out.
Thanks
John Dammeyer
procedure TForm1.SrvSocketSessionAvailable(Sender: TObject; ErrCode: Word);
var
NewHSocket : TSocket;
PeerName : TSockAddrIn;
Peer : String;
begin
PortEdit.Enabled := TRUE;
{ We need to accept the client connection }
NewHSocket := SrvSocket.Accept;
{ And then associate this connection with our client socket }
CliSocket.Dup(NewHSocket);
{ Wants to know who is connected to display on screen }
CliSocket.GetPeerName(PeerName, Sizeof(PeerName));
{ User likes to see internet address in dot notation }
Peer := IntToStr(ord(PeerName.sin_addr.S_un_b.s_b1)) + '.' +
IntToStr(ord(PeerName.sin_addr.S_un_b.s_b2)) + '.' +
IntToStr(ord(PeerName.sin_addr.S_un_b.s_b3)) + '.' +
IntToStr(ord(PeerName.sin_addr.S_un_b.s_b4));
InfoLabel.Caption := 'Remote ' + Peer +
' connected. Port:' + CliSocket.GetPeerPort;
{ Send a welcome message to the client }
//CliSocket.SendStr('Hello' + #13 + #10);
{ Enable the server user to disconect the client }
DisconnectButton.Enabled := TRUE;
InitDisplayButton.Enabled := TRUE;
end;
--
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
Re: [twsocket] EIcsException 'No more free message'
All is well now. Sorry for the trouble. I was calling GetHandle which was
calling allocatehwnd internally after the threaddetach... That was the
problem.
THANKS!
SZ
- Original Message -
From: "Francois PIETTE" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Saturday, June 10, 2006 6:17 PM
Subject: [twsocket] EIcsException 'No more free message'
>I built a small test to verify TIcsWndHandlerPool.GetWndHandler and it
>works
> perfectly. So the problem is elsewhere.
>
> Are you deriving a component from an ICS component ?
> If you do, be sure to respect the rules with AllocateMsgHandlers,
> FreeMsgHandlers and MsgHandlersCount. If you don't, you may have the error
> you get.
>
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
>
> - Original Message -
> From: "Francois PIETTE" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Saturday, June 10, 2006 4:55 PM
> Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
>
>
>> Something wrong in TIcsWndHandlerPool.GetWndHandler ?
>>
>> --
>> [EMAIL PROTECTED]
>> http://www.overbyte.be
>>
>> - Original Message -
>> From: "Fastream Technologies" <[EMAIL PROTECTED]>
>> To: "ICS support mailing"
>> Sent: Saturday, June 10, 2006 9:20 AM
>> Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
>>
>>
>>> Now I get this exception:
>>>
>>> function TIcsWndHandler.AllocateMsgHandler(Obj: TIcsWndControl): UINT;
>>> var
>>>I : UINT;
>>> begin
>>>if FMsgLow < WM_USER then
>>>raise EIcsException.Create('MsgLow not defined');
>>>if FMsgCnt >= WH_MAX_MSG then
>>>raise EIcsException.Create('No more free message'); // FIRED
>>> after
>>> a
>>> dozen page views!!!
>>>I := 0;
>>>
>>> Any idea?
>>>
>>> Regards,
>>>
>>> SZ
>
> --
> 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
[twsocket] EIcsException 'No more free message'
I built a small test to verify TIcsWndHandlerPool.GetWndHandler and it works
perfectly. So the problem is elsewhere.
Are you deriving a component from an ICS component ?
If you do, be sure to respect the rules with AllocateMsgHandlers,
FreeMsgHandlers and MsgHandlersCount. If you don't, you may have the error
you get.
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Francois PIETTE" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Saturday, June 10, 2006 4:55 PM
Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
> Something wrong in TIcsWndHandlerPool.GetWndHandler ?
>
> --
> [EMAIL PROTECTED]
> http://www.overbyte.be
>
> - Original Message -
> From: "Fastream Technologies" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Saturday, June 10, 2006 9:20 AM
> Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
>
>
>> Now I get this exception:
>>
>> function TIcsWndHandler.AllocateMsgHandler(Obj: TIcsWndControl): UINT;
>> var
>>I : UINT;
>> begin
>>if FMsgLow < WM_USER then
>>raise EIcsException.Create('MsgLow not defined');
>>if FMsgCnt >= WH_MAX_MSG then
>>raise EIcsException.Create('No more free message'); // FIRED after
>> a
>> dozen page views!!!
>>I := 0;
>>
>> Any idea?
>>
>> Regards,
>>
>> SZ
--
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
Re: [twsocket] ICSv6 Thread Attach/Detach problem
Something wrong in TIcsWndHandlerPool.GetWndHandler ?
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Fastream Technologies" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Saturday, June 10, 2006 9:20 AM
Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
> Now I get this exception:
>
> function TIcsWndHandler.AllocateMsgHandler(Obj: TIcsWndControl): UINT;
> var
>I : UINT;
> begin
>if FMsgLow < WM_USER then
>raise EIcsException.Create('MsgLow not defined');
>if FMsgCnt >= WH_MAX_MSG then
>raise EIcsException.Create('No more free message'); // FIRED after
> a
> dozen page views!!!
>I := 0;
>
> Any idea?
>
> Regards,
>
> SZ
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Friday, June 09, 2006 3:56 PM
> Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
>
>
> : Fastream Technologies wrote:
> : > Please realize the async nature of the SELECT. Is there any way we
> : > change this to SYNC because it ruins synchronization.
> :
> : AFAIK winsock API function WSAAsyncSelect() is a common, blocking
> : function. In this case it's called to disable winsock notifications.
> : Because the window is detached/destroyed in subsequent lines.
> : BTW: Same is done in V5.
> : So for a short while the detached socket is windowless, that's
> : why I suggested to wait w/o processing messages until it is
> : attached again (not nice but worked for me). Haven't we talked
> : about the same problem in the SSL-list some months ago?
> :
> : ---
> : Arno Garrels [TeamICS]
> : http://www.overbyte.be/eng/overbyte/teamics.html
> :
> : >
> : > Regards,
> : >
> : > SubZero
> : >
> : > - Original Message -
> : > From: "Fastream Technologies" <[EMAIL PROTECTED]>
> : > To: "ICS support mailing"
> : > Sent: Friday, June 09, 2006 2:41 PM
> : > Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
> : >
> : >
> : >> It worked here as well. But I have another guess: my case is a bit
> : >> different than what you demoed. In my case the client is connected
> : >> to a server while its thread is being changed. So,
> : >>
> : >> procedure TCustomWSocket.ThreadDetach;
> : >> begin
> : >>if (GetCurrentThreadID = DWORD(FThreadID)) and (FHSocket <>
> : >> INVALID_SOCKET) then
> : >>WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0);
> : >> // THIS LINE IS CALLED
> : >>inherited ThreadDetach;
> : >> end;
> : >>
> : >> Could this be the problem? This code is called in
> : >> THttpCli.CtrlSocket.
> : >>
> : >> Best Regards,
> : >>
> : >> SZ
> : --
> : 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
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
--
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
[twsocket] Enhancements for Thread Attach/Detach methods
> AFAIK winsock API function WSAAsyncSelect() is a common, blocking > function. In this case it's called to disable winsock notifications. > Because the window is detached/destroyed in subsequent lines. > BTW: Same is done in V5. > So for a short while the detached socket is windowless, that's > why I suggested to wait w/o processing messages until it is > attached again (not nice but worked for me). To be safe, the order should be: 1) Stop notifications from winsock (WSAAsyncSelect) to the current (old) hidden window 2) Create the new hidden window 3) Extract all messages from old hidden window queue and push them to the new queue 4) Restart notifications from winsock to the new hidden window Probably a good idea to post a FD_READ message in the new queue between 3 and 4 above. Because it may happend that data has been received during the time interval when notifications have been disabled. -- [EMAIL PROTECTED] 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
Re: [twsocket] 64-Bit Processors Issue
Hello Marcelo, Your problem has nothing to do with AMD processors. It was by coincidence that the machine that produced the problem had an AMD processor. You should try an Intel one also. As far as I know, socket implementations doesn't depend on or differ by processor type. They should not. When you track down a problem, first always try to find the cause in YOUR work, among the things that YOU did. People (including myself) are feeble and tend to forget this. The more experience one has, the higher the probability is, to forget the above. Colleagues, NEVER forget it ! I wish good luck for everyone ! Cheers, Peter On Fri, 09 Jun 2006 22:58:14 +0200, Marcelo Grossi <[EMAIL PROTECTED]> wrote: > Hello again folks, > > I managed to "fix" the bug I told you guys about. Aparently it is endeed > an ICS related problem or AMD's fault, can't be concise on that. Here's an > overview of the problem with the solution in sample codes: > > Problem: The server did not received the packet from the client, only > the first one. The packets in question were being sent from inside a for > loop (small one, about 50 iterations). Here is a sample code of the "faulty" > version of the code (Delphi 6): > > for I := 0 to Count-1 do > begin > // This line being the assembly of the buffer, > // it is a very clean code and is a very fast function and very few > data. > // Buffer size estimations are about 20- bytes. > BuildMessage(aString, aBuffer); > // sends rapid-fire buffers to the server > Socket.Send(@aBuffer[0], Length(arBuffer)); > end; > > Solution: Using the cumulative send function provided with ICS the > problem is strangely resolved and the server receves ok the buffers (in this > case, the single buffer made of the small buffers). Here is the sample code: > > for I := 0 to Count-1 do > begin > // Same buffer assemblage > BuildMessage(aString, aBuffer); > // Only sends the packet when the processing is finished (last > iteration) > if I = (Count - 1) then > Socket.Send(@aBuffer[0], Length(aBuffer)) > else >Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); > end; > > I hope I could be of any help and I'm pretty sure this can be reproduced > (using the sample codes above) in any client/server model being the client > an AMD 64-Bit processor (can't say much about Intel 64-Bit processors > because we could not test it out). Anyways, thank you very much for all your > responses! > > Best regards, > > Marcelo Grossi > > - Original Message - > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" > Sent: Friday, June 09, 2006 8:24 AM > Subject: Re: [twsocket] 64-Bit Processors Issue > > >> Marcelo Grossi wrote: >>> Hello again, >>> >>> I'm new to this list and since I've been getting your messages, I >>> was wondering if anyone got the message I sent about the problem I'm >>> having with the 64-Bit AMD processors. I really really need your help >>> on this, because I've never altered the source code of ICS and the >>> problem mentioned (see below) only happens with users of 64-bit AMD >>> (never tested with Intel) processors. >> >> It is very very unlikely that ICS in combination with AMD64 is the >> reason. I personally had troubles with hardware DEP (nx-flag) caused >> by another third party component, however I got at least a very strange >> exception. >> >> --- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >> -- >> 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 >> > -- FIGYELEM ! Ennek a levélnek a végén NINCS REKLÁM !!! észrevetted ? -- 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
Re: [twsocket] 64-Bit Processors Issue
I don't see why your first version could not work. I have programs which basically does the same thing (calling several Send in a row). And I can't imagine why an AMD processor whould fail doing that ! btw: Your second versin is much faster (well 50 iterations probably doesn't do any difference). You can also make the code a little bit clear by removing the test and puting one more send at the end of the loop: for I := 0 to Count-1 do begin // Same buffer assemblage BuildMessage(aString, aBuffer); Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); end; Socket.Send(nil, 0); -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: "Marcelo Grossi" <[EMAIL PROTECTED]> To: "ICS support mailing" Sent: Friday, June 09, 2006 10:58 PM Subject: Re: [twsocket] 64-Bit Processors Issue > Hello again folks, > >I managed to "fix" the bug I told you guys about. Aparently it is > endeed > an ICS related problem or AMD's fault, can't be concise on that. Here's an > overview of the problem with the solution in sample codes: > >Problem: The server did not received the packet from the client, only > the first one. The packets in question were being sent from inside a for > loop (small one, about 50 iterations). Here is a sample code of the > "faulty" > version of the code (Delphi 6): > > for I := 0 to Count-1 do >begin >// This line being the assembly of the buffer, >// it is a very clean code and is a very fast function and very few > data. >// Buffer size estimations are about 20- bytes. >BuildMessage(aString, aBuffer); >// sends rapid-fire buffers to the server >Socket.Send(@aBuffer[0], Length(arBuffer)); >end; > >Solution: Using the cumulative send function provided with ICS the > problem is strangely resolved and the server receves ok the buffers (in > this > case, the single buffer made of the small buffers). Here is the sample > code: > > for I := 0 to Count-1 do >begin >// Same buffer assemblage >BuildMessage(aString, aBuffer); >// Only sends the packet when the processing is finished (last > iteration) >if I = (Count - 1) then >Socket.Send(@aBuffer[0], Length(aBuffer)) >else > Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); >end; > >I hope I could be of any help and I'm pretty sure this can be > reproduced > (using the sample codes above) in any client/server model being the client > an AMD 64-Bit processor (can't say much about Intel 64-Bit processors > because we could not test it out). Anyways, thank you very much for all > your > responses! > > Best regards, > > Marcelo Grossi > > - Original Message - > From: "Arno Garrels" <[EMAIL PROTECTED]> > To: "ICS support mailing" > Sent: Friday, June 09, 2006 8:24 AM > Subject: Re: [twsocket] 64-Bit Processors Issue > > >> Marcelo Grossi wrote: >>> Hello again, >>> >>> I'm new to this list and since I've been getting your messages, I >>> was wondering if anyone got the message I sent about the problem I'm >>> having with the 64-Bit AMD processors. I really really need your help >>> on this, because I've never altered the source code of ICS and the >>> problem mentioned (see below) only happens with users of 64-bit AMD >>> (never tested with Intel) processors. >> >> It is very very unlikely that ICS in combination with AMD64 is the >> reason. I personally had troubles with hardware DEP (nx-flag) caused >> by another third party component, however I got at least a very strange >> exception. >> >> --- >> Arno Garrels [TeamICS] >> http://www.overbyte.be/eng/overbyte/teamics.html >> >> -- >> 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
Re: [twsocket] ICSv6 Thread Attach/Detach problem
Now I get this exception:
function TIcsWndHandler.AllocateMsgHandler(Obj: TIcsWndControl): UINT;
var
I : UINT;
begin
if FMsgLow < WM_USER then
raise EIcsException.Create('MsgLow not defined');
if FMsgCnt >= WH_MAX_MSG then
raise EIcsException.Create('No more free message'); // FIRED after a
dozen page views!!!
I := 0;
Any idea?
Regards,
SZ
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Friday, June 09, 2006 3:56 PM
Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
: Fastream Technologies wrote:
: > Please realize the async nature of the SELECT. Is there any way we
: > change this to SYNC because it ruins synchronization.
:
: AFAIK winsock API function WSAAsyncSelect() is a common, blocking
: function. In this case it's called to disable winsock notifications.
: Because the window is detached/destroyed in subsequent lines.
: BTW: Same is done in V5.
: So for a short while the detached socket is windowless, that's
: why I suggested to wait w/o processing messages until it is
: attached again (not nice but worked for me). Haven't we talked
: about the same problem in the SSL-list some months ago?
:
: ---
: Arno Garrels [TeamICS]
: http://www.overbyte.be/eng/overbyte/teamics.html
:
: >
: > Regards,
: >
: > SubZero
: >
: > - Original Message -
: > From: "Fastream Technologies" <[EMAIL PROTECTED]>
: > To: "ICS support mailing"
: > Sent: Friday, June 09, 2006 2:41 PM
: > Subject: Re: [twsocket] ICSv6 Thread Attach/Detach problem
: >
: >
: >> It worked here as well. But I have another guess: my case is a bit
: >> different than what you demoed. In my case the client is connected
: >> to a server while its thread is being changed. So,
: >>
: >> procedure TCustomWSocket.ThreadDetach;
: >> begin
: >>if (GetCurrentThreadID = DWORD(FThreadID)) and (FHSocket <>
: >> INVALID_SOCKET) then
: >>WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0);
: >> // THIS LINE IS CALLED
: >>inherited ThreadDetach;
: >> end;
: >>
: >> Could this be the problem? This code is called in
: >> THttpCli.CtrlSocket.
: >>
: >> Best Regards,
: >>
: >> SZ
: --
: 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
