Re: [twsocket] best way for packet routing
Hi, yes I know that packets are biggest than 4 bytes on wire, I'm telling about payload only. [40(eth)+20(ip)+20(tcp)+4(payload)]*1000(pktps)*8(bits)*500(clients)=336Mbps1Gbps My intention is to stress the software and understand what happens in critical situations. If I use bigger packets I can easily saturate the gigabit switch, but what I want is to send a lot of packets to a lot of clients using less bandwidth as possible. Do you think that routing cicle is ok? There is a better way to do that? Can you give any advice about that? Thank you Il 27/02/2012 20:50, François Piette ha scritto: For this I configured each client to send about 1000 packets per second of 4 bytes (about 32Kbps). Your bps computation is wrong. You send 4 data bytes, the actual packets on the network are much larger (something like 10 times) ! Have a lokk there: http://sd.wareonearth.com/~phil/net/overhead/ You should avoid transmitting such small packet. It is better to aggregate small packets into larger ones. fSS.Client [i]. Send (fRxData, lSize) Add a try/except block around that line. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] best way for packet routing
Hi, I'm doing some tests to evaluate the performance of my application server. I'm using a tcp socket server on a single thread (dedicated, I don't use the main thread), connected with 500 clients installed on different machines (no clients on the server machine). What I want to evaluate is the ability of the server to process packets. For this I configured each client to send about 1000 packets per second of 4 bytes (about 32Kbps). I'm using a gigabit switch, so I don't have any bandwidth problem. In a first test, each client transmits and the server only receives. In this case, the CPU of the server exceeds 50% (on my dual core machine), some clients will stop transmitting (WSAEWOULDBLOCK) and if I analyze the traffic with wireshark, I noticed that the window size of some of the tcp connections goes to zero. Letting go of the transmission for several hours, the clients contended the server. As some clients stopped, the others begin to transmit. For make worse server performance I also introduced a loop inside the receive routine like this: for i: = 0 to 20 do Sleep (0); I believe that the behavior of the server is correct. In a second test, however, have meant that the server performs the routing of packets it receives to other clients. In this case, I make sure that only few clients transmit data (max 6), while all receive. The result I get in this scenario is that clients that stops to trasmit, will not start more. The behavior gets worse if data are routed also to the socket from which the data are coming (in this case the CPU is much higher). The code I use on OnDataAvailable is: for i: = 0 to fSS.ClientCount-1 do begin / / If fSS.Client [i] TWSocketClient (Sender) then begin if fSS.Client [i]. State = wsConnected then fSS.Client [i]. Send (fRxData, lSize) end; end; I would figure out what the best way to route packets. What I like is that even in this case, clients contended the server without stalling. Thanks for the help -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] udp server and network configuration changes
Hi Arno, I'll try it as soon as possible. Thank you, Bye - Messaggio originale - Da: Arno Garrels arno.garr...@gmx.de A: ICS support mailing twsocket@elists.org Inviato: Lunedì, 6 febbraio 2012 9:05:52 Oggetto: Re: [twsocket] udp server and network configuration changes Emanuele Bizzarri wrote: Hi Francois, thank you for your response. In the meanwhile, I also have found NotifyAddrChange function. It is already wrapped inside JwaIpHlpApi by jedi project. For now I'm using network interface polling. Check out the IPv6 branch, SVN rev. #888, since ICS IPv6 uses winsock2 these new events could be added: IPv6 TWSocket Windows - Added events OnAddressListChanged and OnRoutingInterfaceChanged. Assigning event handlers to those properties before a call to methods Connect or Listen ensures that the event notifications are registered and events are triggered when they occur. Assigning handlers to those properties after Connect or Listen (if new ComponentOptions wsoNotifyAddressListChange or wsoNotifyRoutingInterfaceChange are _not set) requires an additional call to new methods SetAddressListChangeNotification and/or SetRoutingInterfaceChangeNotification in order to receive those notifications. Note that once one of these events triggered it has to be re-enabled, they are edge-triggered. svn://svn.overbyte.be/ics/branches/icsipv6 Use username = ics and password = ics for read access -- Arno Garrels Bye - Messaggio originale - Da: François Piette francois.pie...@skynet.be A: ICS support mailing twsocket@elists.org Inviato: Venerdì, 3 febbraio 2012 18:37:02 Oggetto: Re: [twsocket] udp server and network configuration changes There is a way to recognize networks changes like these? Have a look at IP Helper API: http://msdn.microsoft.com/en-us/library/aa366329(VS.85).aspx -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] udp server and network configuration changes
Hi Francois, thank you for your response. In the meanwhile, I also have found NotifyAddrChange function. It is already wrapped inside JwaIpHlpApi by jedi project. For now I'm using network interface polling. Bye - Messaggio originale - Da: François Piette francois.pie...@skynet.be A: ICS support mailing twsocket@elists.org Inviato: Venerdì, 3 febbraio 2012 18:37:02 Oggetto: Re: [twsocket] udp server and network configuration changes There is a way to recognize networks changes like these? Have a look at IP Helper API: http://msdn.microsoft.com/en-us/library/aa366329(VS.85).aspx -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] udp server and network configuration changes
Hi, I've an udp socket listening on ip:port. If I make some network configuration changes, no socket error will be triggered. Is it normal? I've tested following cases: 1. switching off wifi: netstat tells that the socket is listening yet. And it will continue receive data (I've tried from a client on the same pc). If I stop and then restart listening, the ip is available 2. changing ip from control panel: netstat tells that the socket is listening yet. But data transfer is interrupted. If I reconfigure the previous ip, data transfer begins again. Is this the windows behaviour? There is a way to recognize networks changes like these? I haven't tried with a listening tcp socket yet. Will it be able to recognize network configuration changes? If yes, I could use it in combination with my udp socket. Thank you in advance Emanuele -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] squid NTLM proxy support
Hi Arno,
thankyou for your response.
I agree with you that OverbyteIcsNtlmMsgs.pas only supports Unicode
NTLM messages. However I recently implemented proxy support in TWSocket
and tested that stuff against Squid proxy, it did work with current
OverbyteIcsNtlmMsgs.pas fine. So at least that version of Squid I used
for testing must have supported Unicode.
I'm using IPCOP 1.4.21 (latest available).
This is the configuration of squid:
Squid Cache: Version 2.7.STABLE9
configure options: '--prefix=/usr' '--sysconfdir=/etc/squid'
'--datadir=/usr/lib/squid' '--libexecdir=/usr/lib/squid'
'--enable-storeio=null,aufs,coss,diskd,ufs'
'--enable-removal-policies=heap,lru' '--enable-delay-pools'
'--enable-follow-x-forwarded-for' '--enable-useragent-log'
'--enable-referer-log' '--enable-arp-acl' '--enable-http-violations'
'--enable-linux-netfilter' '--enable-ident-lookups'
'--enable-auth=basic,ntlm' '--enable-ntlm-fail-open'
Maybe you have tested a newer version (3.1?)
I've checked the squid release note, here:
http://www.squid-cache.org/Versions/v3/3.1/RELEASENOTES.html
but I can't understand how to enable unicode inside ntlm auth.
This is what they say about ntlm:
auth_param ntlm, basic, digest
BASIC, DIGEST: New parameter option utf8 on|off to permit helpers to
selectively process UTF-8 characters even though HTTP accepts only
ISO-8859-1.
NTLM: The helper binary bundled with Squid under the name ntlm_auth has
been renamed to accurately reflect its real behavior and to prevent
confusion with the more useful Samba helper using the same name.
Despite being used for NTLM, the helper does not in fact provide true
NTLM function. What it does provide is SMB LanManager authentication
through the NTLM interface without the need for a domain controller.
Thus the new name is ntlm_smb_lm_auth.
WARNING: due to the name clash with Samba helper, admin should be
careful to only update their squid.conf if the Squid bundled binary is
used and needed. If the Samba helper is in use, the squid.conf should
not be altered.
If this actually requires a fix there should be a solution that can
be used in all components not just a separate fix for the HTTP client
IMO.
You're right: the fix should be applied also where necessary
(OverbyteIcsNTLMSSP, OverbyteIcsPOP3Prot, OverbyteIcsPp3ProtOld,
OverbyteIcsSMTPProt).
Up to now I've never used these units, so I have not changed them.
Whether Unicode or OEM strings are used in the NTLM communication
should be an implementation detail hidden to the component user.
Your fix doesn't fix for instance the NtlmGetMessage2 result,
I wonder what the TNTLM_Msg2_Info result looks like with your proxy?
If I debug NtlmGetMessage2 function, I see:
function NtlmGetMessage2(const AServerReply: String): TNTLM_Msg2_Info;
AServerReply='TlRMTVNTUAACCwALACgAAACCgkEATo49y/toC4kAAEUtV09SS1MuTEFO'
NTLMReply='NTLMSSP'#0#2#0#0#0#$B#0#$B#0'('#0#0#0'‚‚A'#0'C'#8'Êlÿô”Ü'#0#0#0#0#0#0#0#0'E-WORKS.LAN'
MsgInfo.Target='E-WORKS.LAN'
MsgInfo.Challenge=(67, 8, 202, 108, 255, 244, 148, 220)
Msg.TargetInfo.Offset=777210706 (it is right?)
then the loop through target information blocks block is skipped.
Do you see something strange?
For now, I keep the patch.
I hope that ipcop will upgrade squid soon.
thankyou,
bye
Emanuele
--
Ing. Emanuele Bizzarri
Software Development Department
e-works s.r.l.
41011 - Campogalliano - Modena - Italy
tel. +39 059 2929081 int. 23
fax +39 059 2925035
e-mail: e.bizza...@e-works.it - http://www.e-works.it
-
La presente comunicazione, che potrebbe contenere informazioni riservate
e/o protette da segreto professionale, è indirizzata esclusivamente ai
destinatari della medesima qui indicati. Le opinioni, le conclusioni e
le altre informazioni qui contenute, che non siano relative alla nostra
attività caratteristica, devono essere considerate come non inviate né
avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono
soggetti ai termini ed alle condizioni previsti dagli accordi che
regolano il nostro rapporto con il cliente. Nel caso in cui abbiate
ricevuto per errore la presente comunicazione, vogliate cortesemente
darcene immediata notizia, rispondendo a questo stesso indirizzo di
e-mail, e poi procedere alla cancellazione di questo messaggio dal
Vostro sistema. E' strettamente proibito e potrebbe essere fonte di
violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei
contenuti di questa comunicazione da parte di chi la abbia ricevuta per
errore o in violazione degli scopi della presente.
-
This communication, that may contain confidential and/or legally
privileged information, is intended solely for the use of the intended
addressees. Opinions, conclusions and other information contained in
this message, that do not relate to the official business of this firm,
shall be considered
Re: [twsocket] squid NTLM proxy support
Hi, I used the Windows port version 2.7stable8, that might be the difference? Here's my squid.conf: auth_param ntlm program C:/Squid/libexec/mswin_ntlm_auth.exe -A Users auth_param ntlm children 5 auth_param ntlm keep_alive on [..] Authentication is delegated to external helper apps. In my case auth is delegated to a win2003 domain server So that's obviously ANSI and the message is currently not parsed correctly. So I also have to re-implement Base64Decode, inside NtlmGetMessage2? Right? (I'm using Delphi2007) Have you tried to remove Flags_Negotiate_OEM from the flags in: Yes I've tried, but without success. :( Bye, Emanuele -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] squid NTLM proxy support
It works! From now I will use the svn version, and I will eliminate my patch. Tell me if you want to try your next code changes on my proxy. Thank you very much!!! Emanuele Il 22/07/2011 15:51, Arno Garrels ha scritto: emanuele bizzarri wrote: Hi, I used the Windows port version 2.7stable8, that might be the difference? Here's my squid.conf: auth_param ntlm program C:/Squid/libexec/mswin_ntlm_auth.exe -A Users auth_param ntlm children 5 auth_param ntlm keep_alive on [..] Authentication is delegated to external helper apps. In my case auth is delegated to a win2003 domain server So that's obviously ANSI and the message is currently not parsed correctly. So I also have to re-implement Base64Decode, inside NtlmGetMessage2? Right? (I'm using Delphi2007) I just checked in a fix, it is available with a SVN client now or included in next daily snapshot: http://wiki.overbyte.be/wiki/index.php/ICS_Download Please let me know how it works for you since I couldn't test it. My fix doesn't require an extra parser class but added a new boolean field Unicode to record TNTLM_Msg2_Info. Some more string conversions were required. -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] listening on two multicast sockets on the same port
Hi Primoz,
maybe the ReuseAddr property?
This is my Implementation:
procedure TUDP.StartRx;
begin
Disconnect;
pLocalIP:=trim(pLocalIP);
if (pLocalIP'')and(pLocalPort0) then
begin
fWS.Proto:='udp';
fWS.MultiThreaded:=pMultiThreaded;
fWS.Addr:=pLocalIP;
fWS.Port:=inttostr(pLocalPort);
if fWS.Addr='' then
fWS.Addr:='0.0.0.0';
if pMulticast then
begin
fWS.MultiCast:=true;
fWS.ReuseAddr:=true;
fWS.MultiCastAddrStr:=pPeerIP;
end;
fWS.Listen;
fWS.SocketRcvBufSize:=fRXSize;
if pMulticast then
setsockopt(fWS.HSocket,IPPROTO_IP,IP_MULTICAST_TTL,@pMulticastTTL,sizeof(pMulticastTTL));
end
else
TLogger.Log('UDP socket start rx error LocalIP='+pLocalIP+'
LocalPort='+inttostr(pLocalPort),lsError,true);
end;
Bye
Emanuele
Il 16/06/2011 12:29, Primoz Gabrijelcic ha scritto:
Hello, Everybody!
I have some problems with multicasting implementation, most probably
caused by my insufficient understanding of the subject.
I have multiple applications that can stream and listen on multicasted
traffic. Because I want them to bind only to one physical interface,
I'm initializing receiving socket as follows:
Port := 9200; // multicast port
Addr := '172.16.1.1'; // IP address of the physical adapter I want to
bind to
MultiCastAddrStr := '239.192.1.1';
MultiCast := true;
Proto := 'udp';
This works fine as long as I only want to listen from one program on
this computer. As soon as I start the second instance which binds to
the same multicast address and port, the second .Listen fails with
error 10048.
I was living under understanding that it's entirely possible to listen
on the same multicast socket from more than one application on a
single computer and VLC player confirms me in those beliefs - I can
easily start two VLCs on same multicast address:port and both will
play incoming video.
Most probably the error is just in my understanding of how
multicasting is implemented inside ICS. Can you please point to the
error in my approach?
Best regards,
Primoz
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
Ing. Emanuele Bizzarri
Software Development Department
e-works s.r.l.
41011 - Campogalliano - Modena - Italy
tel. +39 059 2929081 int. 23
fax +39 059 2925035
e-mail: e.bizza...@e-works.it - http://www.e-works.it
-
La presente comunicazione, che potrebbe contenere informazioni riservate
e/o protette da segreto professionale, è indirizzata esclusivamente ai
destinatari della medesima qui indicati. Le opinioni, le conclusioni e
le altre informazioni qui contenute, che non siano relative alla nostra
attività caratteristica, devono essere considerate come non inviate né
avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono
soggetti ai termini ed alle condizioni previsti dagli accordi che
regolano il nostro rapporto con il cliente. Nel caso in cui abbiate
ricevuto per errore la presente comunicazione, vogliate cortesemente
darcene immediata notizia, rispondendo a questo stesso indirizzo di
e-mail, e poi procedere alla cancellazione di questo messaggio dal
Vostro sistema. E' strettamente proibito e potrebbe essere fonte di
violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei
contenuti di questa comunicazione da parte di chi la abbia ricevuta per
errore o in violazione degli scopi della presente.
-
This communication, that may contain confidential and/or legally
privileged information, is intended solely for the use of the intended
addressees. Opinions, conclusions and other information contained in
this message, that do not relate to the official business of this firm,
shall be considered as not given or endorsed by it. Every opinion or
advice contained in this communication is subject to the terms and
conditions provided by the agreement governing the engagement with such
a client. If you have received this communication in error, please
notify us immediately by responding to this email and then delete it
from your system. Any use, disclosure, copying or distribution of the
contents of this communication by a not-intended recipient or in
violation of the purposes of this communication is strictly prohibited
and may be unlawful.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Multicast question
Il 26/05/2011 15:28, Éric Fleming Bonilha ha scritto:
Hi Emanuele,
Thanks for the examples
I actually have a working application with multicast, but I was
wondering if it was correct, because I tested it with a switch that
manages IGMP and no multicast groups were being created.
I saw that you set TTL to 32, why? The default 1 would not work? I know
that 1 would work just on local network (My case)
I used multicast on wan. Our customer wanted this setting.
What I´m confused is with the group creation, how my ICS based
application with create a multicast group that is visible for switches
(By using IGMP) and switches can manage this multicast distribution?
Without that, multicast would be just like broadcast.
Using wireshark, when a multicast socket enter in listening state, you
should see igmp packets on the net.
These packets should tell to the switch how to manage multicast
distribution.
I saw on TWSocket source that when I start listening it actually sets
the socket to ADD_MEMBERSHIP tp the group, this may be OK for receiving
data, but I´m confused about sending multicast data, because the sender
is the one that was supposed to create the multicast group right? But to
send multicast data on network I need to use Connect method instead of
Listen from the TWSocket, in this case, on Connect method I didn´t find
a mention to ADD_MEMBERSHIP or creating a multicast group.
In my implementation, I start listening also for the sender, using
TUDP.SetTx and TUDP.StartRx methods. I use TUDP.Connect method, only for
send udp unicast packets.
I'm not a multicast expert. I found this kind of solution that worked in
my scenario.
Using my implementation, what kind of packet distribution do you get?
Broadcast?
Bye
Thanks
Eric
-Mensagem Original- From: emanuele bizzarri
Sent: Thursday, May 26, 2011 3:41 AM
To: twsocket@elists.org
Subject: Re: [twsocket] Multicast question
Hi,
this is an example of TUDP class that can be used in multicast (receive
and transmit).
This unit depends by other units, but you can easily extract what you need.
Note that I set multicast ttl.
I hope it will be usefull for you,
Bye
Emanuele
unit ewPlatform_UDP;
interface
uses
ewPlatform_Lists,
ewPlatform_Logger,
ewPlatform_Memory,
ewPlatform_Packets,
ewPlatform_Strings,
OverByteIcsWsocket,
WinSock,
Windows,
SysUtils,
Classes;
type
TOnUDPError=procedure(aError:integer)of object;
TOnUDPDataSent=procedure(aInteger:integer)of object;
TOnUDPDataAvailable=procedure(aSender:TObject;aData:pointer;aSize:integer;aPeerIP:string;aPeerPort:integer)
of object;
TUDP=class
protected
fWS:TWSocket;
fSent:boolean;
fPeerSrc:TSockAddr;
fPeerSrcLen:integer;
fRxData:pointer;
fRxSize:integer;
fWhiteList:TStringList;
fBlackList:TStringList;
fTxList:TStringList;
procedure DataAvailable(aSender:TObject;aError:word);
procedure DataSent(aSender:TObject;aErrCode:word);
procedure DnsLookupDone(aSender:TObject;aErrCode:word);
procedure ChangeState(aSender:TObject;aOldState,aNewState:TSocketState);
procedure Send;
function GetStarted:boolean;
public
pLocalIP:string;
pLocalPort:integer;
pPeerIP:string;
pPeerPort:integer;
pMultiThreaded:boolean;
pMulticast:boolean;
pUseWhiteList:boolean;
pUseBlackList:boolean;
pMulticastTTL:integer;
pGetPeerByData:boolean;
pOnDataSent:TOnUDPDataSent;
pOnDataAvailable:TOnUDPDataAvailable;
pOnError:TOnUDPError;
pOnChangeState:TChangeState;
constructor Create;
destructor Destroy;override;
procedure StartRx;
procedure SetTx;
procedure Disconnect;
procedure Connect;
function Add2WhiteList(aIPPort:string):boolean;
function Add2BlackList(aIPPort:string):boolean;
procedure DeleteFromWhiteList(aIPPort:string);
procedure DeleteFromBlackList(aIPPort:string);
procedure ClearWhiteList;
procedure ClearBlackList;
function NewData(aData:pointer;aSize:integer):integer;
property pStarted:boolean read GetStarted;
end;
implementation
//--
//TUDP
//--
constructor TUDP.Create;
begin
inherited Create;
TLogger.Log('UDP socket creation
threadID='+inttostr(GetCurrentThreadID),lsVerbose,true);
fWS:=TWSocket.Create(nil);
fWS.OnDataAvailable:=DataAvailable;
fWS.OnDataSent:=DataSent;
fWS.OnDnsLookupDone:=DnsLookUpDone;
fWS.OnChangeState:=ChangeState;
fWS.Proto:='udp';
pGetPeerByData:=false;
fTxList:=TStringList.Create;
fSent:=false;
pLocalIP:='0.0.0.0';
pLocalPort:=0;
pPeerIP:='';
pPeerPort:=0;
pMultiThreaded:=false;
pMulticast:=false;
pMulticastTTL:=32;
fWhiteList:=TStringList.Create;
fBlackList:=TStringList.Create;
pUseWhiteList:=false;
pUseBlackList:=false
Re: [twsocket] Multicast question
the IGMP protocol, do I need to implement anything on application layer or does IGMP protocol is implemented on underlying stack automatically? How my application will create a multicast group on network and/or join a group? Thank you very much! Eric -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] udp packet loss
Hi Francois, hi all I cannot reproduce the packet loss on localhost. Strange. I always lose some packets on localhost (at least setting Interval=0 on the client). I can reproduce on different computers, but I found a flaw in your design: remember TWSocket use non blocking. SendTo will fail if winsock is not able to receive data and you don't check that condition. Yes you're right. Now I've modified the code like this: procedure TForm1.OnTimer(aSender:TObject); begin if fWS.State=wsConnected then begin move(fCounter,fData^,4); if (fWS.SendTo(fPeerSrc,fPeerSrcLen,fData,fDataSize)0)or (WSocket_WSAGetLastError=WSAEWOULDBLOCK) then inc(fSent); end; end; procedure TForm1.WSocketDataSent(Sender: TObject; ErrCode: Word); begin if fSent0 then begin dec(fSent); inc(fCounter); inc(fBR,fDataSize); Restart; end; end; Is it right? This is like I do in my real application. I'm not sure you correctly checked with wireshark that all packets where sent actually because their aren't when SendTo fails. I'm pretty sure yes. I've set internal packet number equal to wireshark packet number. Inside wireshark, if I select one lost packet by the server application, I can see that internal packet number corresponds. So I think that this client side bug is not the cause of packet loss. However I've fixed it. Yesterday I have done some tests. I've tried different computers. I noticed that: On localhost I can reach very different max bitrates. From about 90Mbps under winXp (cpu=T2300@1.66GHz), until 250Mbps under win7 (cpu=I72630QM@2.00GHz), but always some packet are lost. On different machines, connected with a cross cable and Gbps ethernet cards (I've installed the udp server over Q9300 2,5GHz machine, using different operating systems), max bitrate is always about 160Mbps but: under winXp a lot of packets are lost. under win7 less packets are lost than using winXp. under ubuntu+wine less packets are lost than using winXp and about the same as win7. If I open wireshark many more packets are lost by the application (not by wireshark). I noticed that if I set: SetPriorityClass (GetCurrentProcess, HIGH_PRIORITY_CLASS); and fUDPServer.Priority:=tpNormal less packets are lost (no improvement if I set also fUDPServer.Priority:=tpTimeCritical); I've tried to compile a third party example of udp server that use winsock in a different way: http://www.tenouk.com/Winsock/Winsock2example9.html under windows and under linux, but the results are like the same. I've also tried Indy project, but no improvement has been obtained. I don't know if my tests are completely correct, but my conclusion is that the mechanism of messaging notification used by windows can create a udp rx bottleneck in some circumstances (system wide and not only application wide). In my real application (where bitrates are two orders of magnitude lower) I've create a thread pool to manage incoming and outcoming data. Data are transferred by threads using async queues (that use win messages) with skip data mechanism where possible. The result is that, however, udp rx is very (too much) sensible to any action done on the system. Now I'm working to reduce this sensibility. I can accept any other kind of compromise, but I'd like that if udp packets phisically arrive on the machine they were not discarded. var lBuffer:array[0..1500] of AnsiChar; I'd advice you not to allocate static buffer inside a method because it is placed inside the stack every time method is called. yes you're right. In my real application buffers are statically allocated. I'm going to modify also the example like you say. Thankyou for help, Emanuele -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] udp packet loss
Hi, I'll assume you use a direct cable or put wireshark at the receiving computer because sending a packet is not a problem. Having the packet reaching the network card of the receiving computer is a different thing if there is something in between. Yes, I use a cross cable and two laptop with 1gbps ethernet cards (CPU1=T8100@2.10GHz CPU2=T2300@1.66GHz). I use wireshark on the udp server machine in this way: 1. Start wireshark on port 9000 (udp server is listening on it). 2. Start udp server (expected packet number is set to 1) 3. Start udp client on the client machine (start sending packets, first packet number=1) 4. When udp server signal packet loss stop the client. 5. If packet loss is not signalled try to resize the udp server form, or reduce time interval on the client (min=0 max speed). 5. Search inside wireshark the expected lost packet: I can see the packet (the first 4 bytes correspond to the wireshark packet number). If I set Interval=0 (max speed) on the client, the bitrate exceeds 100Mbps, but some packets are lost. It is not the messages which interfere, but GUI message processing can be very slow compared to network messages and while a GUI message is processed, no other message of the same thread can be processed. So I've created a worker thread that manage socket in its own message loop. That's perfect. But be sure to avoid using Synchronize or to block your thread while the GUI handle your messages. You really have the thread pumping messages as fast as possible. Just read the UDP socket and put the message in a queue for the GUI thread, then signal the GUI that the queue has a new message and let the thread pump the next message. Look at how your worker thread handle messages. As I said above, it has to be as fast as possible. Just receive the data into some kind of queue and signal it to the GUI thread without ever waiting for the GUI thread to handle the data. Probably not. At least you have to pass data to the GUI thread. This is the windows procedure of the udp server thread: procedure TUDPServer.ThreadWndProc(var aMessage:TMessage); begin if aMessage.Msg=WM_UDP_LISTEN then begin fExpected:=1; fWS.Listen; end; if aMessage.Msg=WM_UDP_CLOSE then begin fWS.Close; end; inherited ThreadWndProc(aMessage); end; and this is the DataAvailable of the socket: procedure TUDPServer.WSocketDataAvailable(Sender: TObject; Error: Word); var lBuffer:array[0..1500] of AnsiChar; lLen:integer; lSrc:TSockAddrIn; lSrcLen:integer; lRx:integer; begin lSrcLen:=SizeOf(lSrc); lLen:=fWS.ReceiveFrom(@lBuffer,SizeOf(lBuffer),lSrc,lSrcLen); if lLen=0 then begin inc(pBR,lLen); move(lBuffer[0],lRx,4); if lRx fExpected then PostMessage(self.fHandle,WM_UDP_DATA,lRx,fExpected); fExpected:=lRx+1; if lLenfExpectedSize then PostMessage(self.fHandle,WM_UDP_SIZE,lLen,fExpectedSize); end; end; If the thread detects a packet loss or a packet size error (size error never happened) it sends a message to the GUI thread (self.fHandle). No other operation is done. One last note: Disable any firewall and security product to do your testing. Many of those security products are trapping network traffic and can slow down thruput and may have bugs. So in case of difficulties like you have, it is better to disable everything and use a bare bone clean computer setup. Of course later you'll turn security back on. Yes I have no firewall. Another thing: I have tried using udp client/server on the same computer, and in this case the packet loss is reached only trasmitting at the max speed possible, but: 1. Wireshark doesn't capture packets on the same machine. 2. The cpu goes very high. So I think that packet loss is possible in this situation. I prefere to use two separated laptops. My client/server project size is only 12KB, is it possible to attach it to the mail? Someone could try it... If you think that could be a good example in order to test network udp performance (and it is not buggy), it could be added to the user made section of the ics site. Thank you, Emanuele -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] udp packet loss
Hi, now I've made a console application for the UDP server, but nothing changes. I see packet loss inside application, but all packets are correctly captured by wireshark. Thankyou, Emanuele Il 27/02/2011 15.09, Francois PIETTE ha scritto: My client/server project size is only 12KB, is it possible to attach it to the mail? Someone could try it... It don't primize, but you may send the source code to me (no executable please) I will try to test it. Include complete projects so that I can test within a few minutes, and instructions to reproduce the issue. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] udp packet loss
Hi,
I've a problem with udp.
Often my application detects packet losses.
In order to systematically reproduce the problem, I've used the
following configuration.
I use 2 pc connected with a cross cable.
The client sends udp numbered packets to the server.
Packet size is 1460. One packet is sent every 1 ms (about 11 Mbps).
I use wireshark to analyze the traffic on the server machine.
I see that all the packets arrive on the server, but not inside the
application.
Packet loss increases if I resize the form, so I've made a worker thread
in order to manage udp server socket messages, but the problem remains.
Have you any suggestion to resolve this problem?
Maybe the socket configuration should be changed?
Thank you for your help,
Emanuele
I attach the code of server, client and worker thread:
Server code
unit Main;
interface
uses
ewPlatform_WorkerThread,
OverbyteIcsWSocket,
WinSock,
Windows,
Messages,
SysUtils,
Variants,
Classes,
Graphics,
Controls,
Forms,
Dialogs, StdCtrls, ExtCtrls;
type
TOnListen=procedure(aSender:TObject;aThreadID:Cardinal)of object;
TOnData=procedure(aSender:TObject;aRx,aSize:integer)of object;
TUDPServer=class(TWorkerThread)
protected
fExpected:integer;
fExpectedSize:integer;
fWS:TWSocket;
procedure DoInit;override;
procedure WSocketSessionConnected(Sender: TObject; Error: Word);
procedure WSocketSessionClosed(Sender: TObject; Error: Word);
procedure WSocketDataAvailable(Sender: TObject; Error: Word);
procedure WndProc(var aMessage:TMessage);override;
procedure ThreadWndProc(var aMessage:TMessage);override;
public
pBR:integer;
pOnListen:TOnListen;
pOnClose:TNotifyEvent;
pOnData:TOnData;
pOnSizeError:TOnData;
destructor Destroy;override;
procedure Listen(aIP:string;aPort:string;aExpectedSize:integer);
procedure Close;
end;
TForm1 = class(TForm)
ButtonStart: TButton;
ButtonStop: TButton;
Memo1: TMemo;
EditIP: TEdit;
EditPort: TEdit;
Timer1: TTimer;
LabelBR: TLabel;
Button1: TButton;
EditExpectedSize: TEdit;
procedure ButtonStartClick(Sender: TObject);
procedure ButtonStopClick(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
procedure Timer1Timer(Sender: TObject);
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
fUDPServer:TUDPServer;
procedure OnListen(aSender:TObject;aThreadID:cardinal);
procedure OnClose(aSender:TObject);
procedure OnData(aSender:TObject;aRx,aExpected:integer);
procedure OnSizeError(aSender:TObject;aRx,aExpected:integer);
public
{ Public declarations }
end;
var
Form1: TForm1;
WM_UDP_LISTEN:cardinal;
WM_UDP_CLOSE:cardinal;
WM_UDP_DATA:cardinal;
WM_UDP_SIZE:cardinal;
implementation
{$R *.dfm}
//--
//TUDPServer
//--
procedure TUDPServer.DoInit;
begin
pBR:=0;
fExpected:=0;
fExpectedSize:=0;
fWS:=TWSocket.Create(nil);
fWS.OnSessionConnected:=WSocketSessionConnected;
fWS.OnSessionClosed:=WSocketSessionClosed;
fWS.OnDataAvailable:=WSocketDataAvailable;
end;
destructor TUDPServer.Destroy;
begin
inherited Destroy;
FreeAndNil(fWS);
end;
procedure TUDPServer.Listen(aIP,aPort:string;aExpectedSize:integer);
begin
fExpectedSize:=aExpectedSize;
fWS.Proto:='udp';
fWS.MultiThreaded:=true;
fWS.Addr:=aIP;
fWS.Port:=aPort;
PostMessage(self.fThreadHandle,WM_UDP_LISTEN,0,0);
end;
procedure TUDPServer.Close;
begin
PostMessage(self.fThreadHandle,WM_UDP_CLOSE,0,0);
end;
procedure TUDPServer.WSocketSessionConnected(Sender: TObject;Error: Word);
begin
PostMessage(self.fHandle,WM_UDP_LISTEN,GetCurrentThreadID,0);
end;
procedure TUDPServer.WSocketSessionClosed(Sender: TObject; Error: Word);
begin
PostMessage(self.fHandle,WM_UDP_CLOSE,0,0);
end;
procedure TUDPServer.WSocketDataAvailable(Sender: TObject; Error: Word);
var
lBuffer:array[0..1500] of AnsiChar;
lLen:integer;
lSrc:TSockAddrIn;
lSrcLen:integer;
lRx:integer;
begin
lSrcLen:=SizeOf(lSrc);
lLen:=fWS.ReceiveFrom(@lBuffer,SizeOf(lBuffer),lSrc,lSrcLen);
if lLen=0 then
begin
inc(pBR,lLen);
move(lBuffer[0],lRx,4);
if lRx fExpected then
PostMessage(self.fHandle,WM_UDP_DATA,lRx,fExpected);
fExpected:=lRx+1;
if lLenfExpectedSize then
PostMessage(self.fHandle,WM_UDP_SIZE,lLen,fExpectedSize);
end;
end;
procedure TUDPServer.WndProc(var aMessage:TMessage);
begin
if aMessage.Msg=WM_UDP_LISTEN then
begin
if assigned(pOnListen) then
pOnListen(self,aMessage.WParam);
end;
if aMessage.Msg=WM_UDP_CLOSE then
begin
if
Re: [twsocket] udp packet loss
Hi Francois, thank you for your response. I've created the socket inside DoInit, that is an override method of the virtual DoInit of the worker thread. The DoInit method is called inside Execute method, so the socket is created by the thread and its messages are handled by it (try to use GetThreadID inside socket callbacks). As you can see in my code I've also try to set tpTimeCritical to thread priority, but without any success. The worker thread check if expected packet number (first four bytes) corresponds to expected packet number. In my example I think that the gui should not interfere with worker thread. I can't use tcp in my application, I need udp. Any ideas? Thank you, Emanuele Il 26/02/2011 16.29, Francois PIETTE ha scritto: I've a problem with udp. Often my application detects packet losses. At first glance, this is expected with UDP. By construction UDP is an unreliable transport. In order to systematically reproduce the problem, I've used the following configuration. I use 2 pc connected with a cross cable. The client sends udp numbered packets to the server. Packet size is 1460. One packet is sent every 1 ms (about 11 Mbps). I use wireshark to analyze the traffic on the server machine. I see that all the packets arrive on the server, but not inside the application. Packet loss increases if I resize the form, so I've made a worker thread in order to manage udp server socket messages, but the problem remains. This is normal. If the application is not able to read UDP packets as fast as packets are incomming, they are simply dropped. There is no flow control with UDP. This is how UDP is working. Have you any suggestion to resolve this problem? The easiest way is to use TCP which is a reliable protocol, with flow control, retries and everything needed to make it reliable. Maybe the socket configuration should be changed? Won't change anything. If you still want to use UDP, you may use a dedicated thread to handle communication and give it a high priority so that it will receive CPU before the user interface. I attach the code of server, client and worker thread: Sorry no time to read your code. i just browsed quickly and see you don't create TWSocket in thread's execute method, so all events are handled by the main thread. This is a flaw in your design, at least. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- To unsubscribe
Re: [twsocket] udp packet loss
Hi, I need to use udp because my application is an h323/sip endpoint. RTP uses udp sockets to transmit/receive audio/video data. RTCP can be used to manage packet loss. But in this case packets are not lost by the network. If I use wireshark I can see all the packets. I think that there is a problem in my code. I know that gui messages can interfere with socket messages. So I've created a worker thread that manage socket in its own message loop. Could be the problem in the way I create/use the message loop in worker thread? This is the execute method (DoInit create the socket): procedure TWorkerThread.Execute; begin DoInit; MessageLoop; end; Inside the message loop method, I allocate fThreadHandle and then begin dispatch messages. procedure TWorkerThread.MessageLoop; var lMsg:TMsg; begin fThreadHandle:=AllocateHWnd(ThreadWndProc); PeekMessage(lMsg,0,0,0,PM_NOREMOVE); SetEvent(fResumeEvent); //GetMessage return false on WM_QUIT while (GetMessage(lMsg,0,0,0))and(not self.Terminated) do begin TranslateMessage(lMsg); DispatchMessage(lMsg); end; DeallocateHWnd(fThreadHandle); end; The DoInit method is called before AllocateHWnd, so the socket is created before. Could be here the problem? It seems that the thread is not fast enought to elaborate socket messages. Or that the gui slow the worker thread in some way. If I call GetCurrentThreadID inside the DataAvailable the result is the id of the worker thread. The only thing done inside the DataAvailable callback is check packet number. The cpu is used about 12%. I've tried to set the process priority (thank you Angus), but nothig changes. What kind of performance do you reach using udp sockets? I think that my performance are not satisfactory. Thank you for your help. Emanuele Il 26/02/2011 21.15, Francois PIETTE ha scritto: As you can see Sorry, no time to examine it in details. Priority is given to my business customers... in my code I've also try to set tpTimeCritical to thread priority, but without any success. The worker thread check if expected packet number (first four bytes) corresponds to expected packet number. I can't use tcp in my application, I need udp. You software, when using UDP, must be preapred to packet loss, duplicate packets and packet in incorrect order. If it is not possible in your case, you can't use UDP. UDP is a simple packet protocol with only best delivery effort. This is not an issue with ICS, it is simple how UDP works. In my example I think that the gui should not interfere with worker thread. Any ideas? If you loose packet, then your software, or the whole computer is not fast enough to handle all packets as they are delivered. Buy a faster computer or optimize the software. Of course also check if your network card is OK and setup for 100 Mbps. I can't use tcp in my application, I need udp. Why do you think you must use UDP ? Why isn't TCP good for you ? -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- Ing. Emanuele Bizzarri Software Development Department e-works s.r.l. 41011 - Campogalliano - Modena - Italy tel. +39 059 2929081 int. 23 fax +39 059 2925035 e-mail: e.bizza...@e-works.it - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business
[twsocket] http digest access authentication
Hi all, exists any THttpCli implementation that support digest access authentication? Thanks, Emanuele -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] http digest access authentication
Hi all, exists any THttpCli implementation that support digest access authentication? Thanks, Emanuele -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] ZeroWindow
Hi, Is it possible to detect TCP ZeroWindow by twsocket in order to stop transmission? Thanks, Emanuele Bizzarri -- 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] ZeroWindow
Hi Francois, yes, it refer to TCP flow control. During TCP transmission, the receiver sends acknoledge packets to the transmitter specifying the Usable Window Size as amount of data he can accept. If Usable Window Size goes to 0 the transmission stops. In my application, this condition is verified when the receiver is not able to process data immediately. Usable Windows Size is progressively reduced until 0. I'd like to stop transmission when this event occours. How can I do to limit transission bitrate if speed is to high? Thanks, Emanuele Bizzarri Francois PIETTE ha scritto: Is it possible to detect TCP ZeroWindow by twsocket in order to stop transmission? I don't know what TCP zero window is, but I'm almost sure you can't do anything with it using ICS. Note that if this refer to TCP flow control, you have nothing to doto stop transmission, it is automatically done by winsock. -- [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] ZeroWindow
:-) The solution could be use a thread to manage winsock messages and a thread to elaborate received data. So DataAvailable do nothing. What do you think about it? Francois PIETTE ha scritto: You simply have to rewrite winsock or at least the TCP part :-) -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: emanuele bizzarri [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Tuesday, June 27, 2006 6:25 PM Subject: Re: [twsocket] ZeroWindow Hi Francois, yes, it refer to TCP flow control. During TCP transmission, the receiver sends acknoledge packets to the transmitter specifying the Usable Window Size as amount of data he can accept. If Usable Window Size goes to 0 the transmission stops. In my application, this condition is verified when the receiver is not able to process data immediately. Usable Windows Size is progressively reduced until 0. I'd like to stop transmission when this event occours. How can I do to limit transission bitrate if speed is to high? Thanks, Emanuele Bizzarri Francois PIETTE ha scritto: Is it possible to detect TCP ZeroWindow by twsocket in order to stop transmission? I don't know what TCP zero window is, but I'm almost sure you can't do anything with it using ICS. Note that if this refer to TCP flow control, you have nothing to doto stop transmission, it is automatically done by winsock. -- [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 -- Ing. Emanuele Bizzarri Software Development Department E-Works s.r.l. Direzionale 70 - Via Giardini 456/c 41100 Modena - Italy tel. +39 059 2929081 fax +39 059 2925035 e-mail: [EMAIL PROTECTED] - http://www.e-works.it - La presente comunicazione, che potrebbe contenere informazioni riservate e/o protette da segreto professionale, è indirizzata esclusivamente ai destinatari della medesima qui indicati. Le opinioni, le conclusioni e le altre informazioni qui contenute, che non siano relative alla nostra attività caratteristica, devono essere considerate come non inviate né avvalorate da noi. Tutti i pareri e le informazioni qui contenuti sono soggetti ai termini ed alle condizioni previsti dagli accordi che regolano il nostro rapporto con il cliente. Nel caso in cui abbiate ricevuto per errore la presente comunicazione, vogliate cortesemente darcene immediata notizia, rispondendo a questo stesso indirizzo di e-mail, e poi procedere alla cancellazione di questo messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. - This communication, that may contain confidential and/or legally privileged information, is intended solely for the use of the intended addressees. Opinions, conclusions and other information contained in this message, that do not relate to the official business of this firm, shall be considered as not given or endorsed by it. Every opinion or advice contained in this communication is subject to the terms and conditions provided by the agreement governing the engagement with such a client. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Any use, disclosure, copying or distribution of the contents of this communication by a not-intended recipient or in violation of the purposes of this communication is strictly prohibited and may be unlawful. -- 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
