[twsocket] wSocketServer issue queuing data unintentionally
I'm writing a proxy type of application for irc and I noticed an issue twice last night that had me puzzled. I have 1 wsocketserver component on my form and I spawn a wsocket client for the remote connection since this is a local proxy. When inbound remote connection data comes in i write the packet data to a Tmemorystream, assemble the data and then fire an event which i then use wsocketserver to send the data over loopback. Everything worked fine until last night when i ran it for a few hours. It seems that i stopped getting updated text in irc and when i opened a packet sniffer my program wasn't sending packets over loopback at all. The socket state was still connected and no errors or exceptions were thrown so it wasn't anything that i had done to create an external issue. About 60-90 seconds later the data appeared on my chat screen and there was quite a bit of it. It seems like the wsocketserver queued and buffered the data for nearly a minute and a half before sending the packets, any ideas on how i can avoid this or maybe how this happened? Most of the wSocketServer properties are default, along with the client and both are not threaded. Only 1 client connection is connected always so that wasn't the issue either, the only thing i think it could be is i had the send flags set to wsSendUrgent instead of SendNormal. LingerOnOff was set to LingerOn, would that affect it maybe? Anyhow i'm lost so i'd appreciate any advice on how to ensure that data is pushed out as soon as I call a send operation rather than have the data build up for some time and then send. -- 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] ReceiveStr/SendStr vs. Receive/Send
Hi guys thanks for your earlier responses they helped lots. I was reading ICS demos and comments from Francois and others and I was wondering of an identical replacement for receivestr and sendstr. I'd like to use an array of char instead since it doesn't need to copy the data multiple times. Is there an exact equivalent that will work no differently? I have a lot of data i am processing and ReceiveStr/SendStr works fine but i'd like it optimized. Can someone show me an example please, most of demos use ReceiveStr and SendStr. brad -- 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] OnDataAvailable event question
I was wondering about something concerning the OnDataAvailable event for Twsocket. If I assign a string to the receivestr function inside the OnDataAvailable event and I have lengthy processing do i miss other OnDataAvailable events and my string clears during the reassignment or is the data appended to the current buffer i'm processing? Brad -- 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] socket programming tcp/udp primer question
I recently read the tcp/udp primer under the overbyte.be support section and the tcp data fragmented packet example using the text string Hello caught my attention because that is something i always wondered about in socket programs. The fact that the data can be split up into multiple packets coming in fragments like he l lo is something i'd like to know how to handle properly. What i mean by this is if i'm expecting the line hello and i'm parsing TCP receive socket data i need to handle hello as a whole word without the fragmentation causing my parser to fail and pass the data on without proper handling. I'm wanting to write a chat client for icq/aim/irc/yahoo or any other major protocol and none of the protocols have set boundaries that are apparent to me. Some end on a series of NUL chars (#0) in Delphi or a numeric (a given number) and so on... I'm pretty new to sockets and i need some advice from the more experienced users which would be you guys. If i'm expecting a 2 KB packet char for char that's using TCP protocol and is guaranteed always to be there no exceptions (enforced strictly through the protocol implementation) how can I force WSocket's OnDataAvailable event to queue the data until it's assembled into one large chunk so i can then process it as if it all arrived that way instead of split up. I'm aware that I will have to set my own boundaries on the begining of the expected data and the end of the packet data so that i can get the big picture and make sure i process it as I need but is there any method you would recommend to force the socket to wait until the rest of the data comes in? Would calling wait() and peeking the data not help at all or would the buffer be overwritten during the wait period instead of concatenated with the data coming in afterwards? Can i see an example by chance or get a professional opinion. -Brad -- 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] assembling data on socket receive
Francois Piette, thanks for responding to my last post about tcp primer. I looked into linemode and it looks very useful. The problem for me is I am writing a chat client with ICS and I'm writing both an unofficial third party irc and yahoo chat client but i'm struggling with handling the receive data because there is not a set boundary for the ending of a packet on yahoo, for example. Each yahoo packet that comes in is required to have a YMSG header which is exactly 4 bytes long followed by an additional 16 bytes which makes up a full 20 byte packet header. The 11th and 12th bytes are the actual packet length. standard packet layout YMSG4 random bytes2 byte packet length1 random byte1 byte service type8 random bytes = 20 byte header If the packet's payload is greater than 255 bytes then the 9th byte is incremented by 1 and the remainder is stored in the 10th byte. So a 9th byte of chr($01) and a 10th byte of chr($E1) would give me a payload length of 481 bytes and by adding 20 you would get the entire packets length which would then be 501 bytes. I can always calculate the packet length like this ord(byte9)*256+ord(byte10)+20 This means that the packets payload is calculated in the 9th and 10th bytes and I'm then adding the 20 byte header to get the whole packets length in bytes. YMSG is an undocumented protocol and has no official RFC tp make matters harder. With that said I'm wondering how I could ensure that i can analyze these packets using this calculation. If I split the data at the 12th byte which is the service type and subtract 11 from the 12th byte position i'm able to extract the packet length and perform calculations but I cannot always guarantee that without using linemode that a -11 position from the 12th byte will exist or even have enough bytes in the receive buffer to copy to according to the packet length. If i'm not making sense to you I can give you a proper example in delphi code if you wish with comments. I'm stuck on the fact that linemode would be perfect for me but unfortunately i don't see a common pattern to go on in order to use linemode since the end of the packet isn't a given set of delimiters. It could be an extended character, a null byte, a set of null bytes etc.. so the only way is finding the 4 byte YMSG packet header and incrementing the position to get the 9th and the 10 bytes for the actual length. Is there any way i can do this properly that you could recommend? I originally wondered about this and figured i could check the packet's length against the current length of the received buffer and if the received buffer was smaller i could repeat an operation until the received buffer was filled again or something of that nature but i'm not sure it that would work out the way i imagined it. If you can offer me advice i could sure use it because i love ics and I would like to get a working example sometime soon, one which is able of processing virtually every packet properly without examining data from a premature OnDataAvailable event trigger. -brad -- 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] TWsocket Threading
Hello ICS users, I was wondering a couple things about ICS because i'm currently in a pickle, a big one and it's driving me literally insane. I've used tclientsocket/tserversocket and indy a bit and when i started to use ICS there was definitely a learning curve because it follows the whole async, fully event driven socket paradigm. I would rather use ICS because i feel that it's the best out of them all. I recently modified the socket spy program I found on the examples section and everything is working great except for one bottleneck, i am doing a ton of inbound data processing which requires several (quite a few lengthy routines) which use while-loops and for-loops extensively and it's weighing down my main thread (i believe). What do you recommend I do guys, the threading examples are helpful however they don't go much into calling several (CPU intensive) functions/procedures. Since this is a proxyying application when there is remote inbound data i will need to copy/examine/modify/delete the string data on the main thread and with some worker threads before I send the data to the local socket. My code is nearly identical to Wilfried's SocketSpy code. The server socket listens on a local port and when a connection is accepted the local socket (server) spawns a (client) and establishes a connection to the remote host/address. If anyone can help me in any way i'd be extremely grateful. If you need anymore information I can show you a quick example of the type of layout i'm looking for with ICS. Thanks for your time, Brad -- 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
