As you may see from the different email address, I am currently off work - I'll look deeper into your traces next week. Many thanks for generating them, anyway.
From a first glance, it seems that the app doesn't do overlapped recv(). (lpOverlapped & completion_func are always NULL), so there should actually be no difference (well I'm now using recvmsg() instead of recv(), and the overhead for 16 bit Winsock apps is definitely larger, but I cannot see why that should slow everything down that much). Perhaps I screwed up the blocking semantics of non-overlapped IO.
Have you generated the traces under exactly the same conditions? Can you explain what exactly you did? Martin
On 17 Jan 2002, Martin Wilck wrote:
As you may see from the different email address, I am currently off work - I'll look deeper into your traces next week. Many thanks for generating them, anyway.
From a first glance, it seems that the app doesn't do overlapped recv(). (lpOverlapped & completion_func are always NULL), so there should actually be no difference (well I'm now using recvmsg() instead of recv(), and the overhead for 16 bit Winsock apps is definitely larger, but I cannot see why that should slow everything down that much). Perhaps I screwed up the blocking semantics of non-overlapped IO.
That's what it looks like to me.
Have you generated the traces under exactly the same conditions? Can you explain what exactly you did?
Martin
To have exactly the same data being transferred, I would have to control both ends of the line, I think. I didn't do that. What exactly do you mean, "what exactly I did?" ;-) I have 2 versions of what is essentially the same app, a - well, functionally, it is sendmail/fetchmail: juno 2 and juno 4. I am not sure what protocol[s] it uses, but the app's internal logs mention postoffice, so maybe some perversion of POP3 or so. Anyway, start the app and it connects to its server, sends any mail queued to go out, and receives any mail the server has, and any ads the server sees fit to give it. I think it compresses/decompresses the data itself. I applied the patches. I sent this by juno 4 without trace: Message-ID: <20020116.183513.134657248.0.lawson_whitney(a)juno.com> The app reported it failed to fetch my mail, try again later. I tried again with a winsock trace, and it succeeded, producing socks.gz I then ran juno 2 with trace, producing winsock.gz. I reversed the patches, which took some time to compile and traced juno 4 again, producing sox.gz... Put it this way: socks.gz and sox.gz are exactly the same app with and without the patches. winsock.gz and winsox.gz are a different version of the app, with and without the patches. Actual traffic is different for each session, but the pattern for each should be the same, if that makes any sense to you. Lawson
Thought I sent that before, but it seems I forgot. Lawson
On Thu, 17 Jan 2002 lawson_whitney(a)juno.com wrote:
Perhaps I screwed up the blocking semantics of non-overlapped IO. That's what it looks like to me.
I can't make sense out of these traces. The numbers of bytes transferred are different, but you were transferring different data. The general pattern of function calls and messages is very similar with and without the patch. Especially the error patterns are similar. If the connection is sluggish anyway, the increased overhead through two more function calls should be negligible. Blocking shouldn't be an issue since the sockets seem to be nonblocking ones. The app seems to be using WSAAsyncSelect() and WS_ioctlsocket() a lot, perhaps my patch conflicts with those. I can't think of a reason, though, because the app is doing everything synchronously. Honestly I don't know how to proceed from here. Obviously I should do some testing of my own before reposting. Can you recommend me a few (16 and 32 apps) Winsock apps that are freely downloadable and reported to run under Wine? Juno seems to be bound to a certain provider, so I'd rather not go for that one now. If you have time, a simultaneous tcpdump might clarify things a bit. But I guess I need to rework my stuff before I send out others for testing again.
I sent this by juno 4 without trace:
That means nothing because I didn't touch the sending code :-(
The app reported it failed to fetch my mail, try again later. I tried again with a winsock trace, and it succeeded, producing socks.gz
Did you try without trace once or several times? Thanks again for you efforts, Martin Btw I don't think I can help with the serial app. I see no indication that overlapped IO plays a role there. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
On Mon, 21 Jan 2002, Martin Wilck wrote:
I can't make sense out of these traces. The numbers of bytes transferred are different, but you were transferring different data. The general pattern of function calls and messages is very similar with and without the patch. Especially the error patterns are similar.
I didn't look at them very carefully, but yes, they did look kind of awfully similar in that way. ...
The app seems to be using WSAAsyncSelect() and WS_ioctlsocket() a lot, perhaps my patch conflicts with those. I can't think of a reason, though, because the app is doing everything synchronously.
Can you recommend me a few (16 and 32 apps) Winsock apps that are freely downloadable and reported to run under Wine? Juno seems to be bound to a certain provider, so I'd rather not go for that one now.
Hmmm, wouldn't, say ftp and telnet and so on use winsocks? I basicaly don't have any 32 bit windows stuff except juno, but I have somewhere on a tar.gz WFW 3.11 that I think will have all those little apps in 16 bit versions I can mail you if you like. Maybe even some 32 bit ones from a freebie AOL CD. I guess any windose browser would use winsocks, too, netscrape if you want a big app, but I think to start ftp or telnet might be easier to test in controlled conditions. I have 32 bit ftp.exe and telnet.exe - maybe wfw 3.11 didn't come with those? Juno is bount to a provider, but the basic mail service is free.
If you have time, a simultaneous tcpdump might clarify things a bit. But I guess I need to rework my stuff before I send out others for testing again.
I'll see if I can do some useful tests.
I sent this by juno 4 without trace:
That means nothing because I didn't touch the sending code :-(
Any time I send something, the app looks for something to receive too. Anyway, it won't consider a send done unless it receives an acknowledgement, I think.
Did you try without trace once or several times?
Just once, I think.
Thanks again for you efforts, Martin
Btw I don't think I can help with the serial app. I see no indication that overlapped IO plays a role there.
Lawson
On Mon, 21 Jan 2002, Martin Wilck wrote:
On Thu, 17 Jan 2002 lawson_whitney(a)juno.com wrote:
Perhaps I screwed up the blocking semantics of non-overlapped IO. That's what it looks like to me.
I can't make sense out of these traces. The numbers of bytes transferred are different, but you were transferring different data. The general pattern of function calls and messages is very similar with and without the patch. Especially the error patterns are similar.
Martin
Btw I don't think I can help with the serial app. I see no indication that overlapped IO plays a role there.
Maybe I was hallucinating, or maybe the juno server was just having a bad half-hour. Sometimes, not often, these sessions can fail for no good reason, or at least not one that has anything to do with program code on this end. I thought maybe trace was changing the timing of things, so I tried the app without a trace, but with tcpdump active. AFAICT, it worked fine. Twice. One other possibility, - the script I used to run the app using wine as last built (instead of the installed wine) invokes it --winver nt40. I don't think I did that earlier, and the app might behave differently. I've installed the patches for now and I'll beat on them a bit more and see if anything shakes loose. Sorry, maybe I put you and me both to a lot of trouble because of an unrelated glitch. I would feel better if somebody else besides me would take a swat at testing these winsock patches, too. Lawson
On Mon, 21 Jan 2002 lawson_whitney(a)juno.com wrote:
Sometimes, not often, these sessions can fail for no good reason, or at least not one that has anything to do with program code on this end. I thought maybe trace was changing the timing of things, so I tried the app without a trace, but with tcpdump active. AFAICT, it worked fine. Twice.
Some good news, after all!!
Sorry, maybe I put you and me both to a lot of trouble because of an unrelated glitch. I would feel better if somebody else besides me would take a swat at testing these winsock patches, too.
Yeah. Well I need to prepare new patches anyway. IE and Netscape on Wine users, where are you ? :-) Thanks again, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
On Tue, 22 Jan 2002, Martin Wilck wrote:
IE and Netscape on Wine users, where are you ? :-)
Thanks again, Martin
If I could work out how to make netscrape use a proxy, maybe I could see what winehq looks like to a cluttered browser :-). Lawson
participants (3)
-
lawson_whitney＠juno.com -
Martin Wilck -
Martin Wilck