|
The remote locations are in different states, so I can't have the working and non-working locations swap PC's But I could have them try another PC at the same location. I could have them try their PC and access the iSeries at my location to see if it makes a difference? I will try these two. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of York, Albert Sent: Thursday, September 11, 2003 11:43 AM To: 'Midrange Systems Technical Discussion' Subject: RE: Socket program problem Does the problem happen regardless of which PC you use? Have you tried using a PC from a location that works correctly? Albert York -----Original Message----- From: John Allen [SMTP:jallen@xxxxxxxxxxx] Sent: Thursday, September 11, 2003 9:14 AM To: 'Midrange Systems Technical Discussion' Subject: RE: Socket program problem Well, I have tried everything I can think of and what you guys suggested and still losing the connection before all data is received by the PC client. I am going to explain what is happening in a bit more detail in the hopes I am doing something wrong. The iSeries is acting as the Server and it sits and waits for the PC Clients to connect. The PC sends a request for a file to the iSeries and then waits for a response back (Event message). The iSeries builds the file and sends it back to the PC one record at a time (in XML format) The building of the file and sending all of the records in XML format takes about 2 seconds. While the iSeries is sending the records, the PC client starts receiving the records in groups (number of records it receives with each receive varies from 1-5 records at a time) Before the PC receives all the records it receives a 10053 WSAECONNABORTED and transmission is terminated. I read somewhere that after sending data I should wait for an ack before proceeding. Does this mean when the iSeries send a single record it should wait til the PC receives it and the PC send an ack back to the iSeries, then the iSeries should send another record etc. etc. ? In this application when the iSeries receives a request (ie PC wants file x) The iSeries spawns off a separate job that builds the file and send the data to the PC. The iSeries never acknowledges to the PC that it got the request. It just builds the file and starts sending records to the PC. When the iSeries program (spawned program) is done sending the records it ends. The PC (client) starts receiving the records and when done receiving the records it displays them. At all 10 remote locations, if the file requested is small (about 10 records) all 10 locations work fine, they receive all data just fine. But when the file requested is larger (about 20 or so records) Two of our 10 remote locations never receive all the data They both consistently get the 10053 WSAECONNABORTED before all records are received. We were going to re-write the application tonight and write it so that whenever the PC or the iSeries sends data (even after each individual( they are going to wait until the other side ack that they received the data and is waiting for the next Is this a waste of my time? The programmers here are just guessing at what it could be, but we are out of ideas except for this rewrite. New program would 1) iSeries waiting for request 2) PC send req to iSeries for file X, then waits for ack from iSeries 3) iSeries receives request for file x, sends ack to the PC that the request was received and spawns Job A to build the file and transmit to PC 4) PC get ack from iseries and waits for data 5) iSeries Job A build file and sends record 1 (with X'FF' at end of record) then waits for ack from PC that the record was received PC receives record 1 and knows it is complete because of x'FF' and send ack to the iSeries 6) iSeries receives ack from PC and the two go back and forth til all records are sent and received. Is there any chance this might fix my problem? John -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement Sent: Monday, September 08, 2003 5:06 PM To: Midrange Systems Technical Discussion Subject: RE: Socket program problem On Mon, 8 Sep 2003, John Allen wrote: > > Would it be abnormal for a PC program to take 2 minutes to read 10,000 > bytes Depends on the speed of the connection and how busy the line is, I guess. 10000 bytes in 2 minutes is what? 666bps? About half the speed of a 1200 baud modem! If the line is VERY busy, I guess that's possible. Seems unlikely, though. I'd say it's more likely that something is wrong with their setup. Either the PC program is poorly written, or theres a problem with the networking between the iSeries and the PC that's causing it to drop packets. > > of data? It takes the iSeries .05 (5 hundredths of a second) to send the > data. > How could the iSeries take 0.05 seconds if the PC takes 2 minutes? Are you just talking about the time it takes to put the data into the buffer? (The time it takes for the send() or write() API to complete?) > I will set it to 240 and see if it makes a difference > I should be able to see if the amount of data received on the PC at least > increase from 16 records currently being read before it ends. Worth a try. > > I will also add a X'FF' at the end of the transmission and change the Client > to look for it to stop receiving data. > If that helps, it'd probably imply that something was written incorrectly in the application. > When I said that the PC is waiting for an acknowledgment that data was ready > to be retrieved I was talking about Windows Event Message. I did not realize > it would receive one for each part of the transmission. So that must not be > the problem. Well, again, it could be if the PC program isn't completely reading all data from the socket's buffer each time. > > I believe (correct me if I am wrong) that the Event message carries with it > the number of bytes to be read from the buffer. > No, there's no byte count associated with the message. (At least not if, as I surmise, he's using the WSAAsyncSelect() API with FD_READ) If you think about it, it wouldn't make sense to give a number of bytes since windows event messages are queued, and the potential exists for a lot of new data to be added to the buffer between the time the message is added to the queue and the time that recv() is called. The way I use that API is to use a non-blocking socket to read the data, and simply read the socket until I get a WSAEWOULDBLOCK error indicating that I've retrieved everything. Good Luck! _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
