* [ECOS] TCP/IP Stack packet regrouping @ 2001-07-16 12:51 Trenton D. Adams 2001-07-16 13:12 ` Grant Edwards 2001-07-16 13:20 ` Jonathan Larmour 0 siblings, 2 replies; 20+ messages in thread From: Trenton D. Adams @ 2001-07-16 12:51 UTC (permalink / raw) To: eCos Discussion I'm curious as to what happens if I send 30K worth of data in one send? Will it all send at one time? What happens if I receive 30K of data, will it receive all 30K at one time? If not, in blocking mode it will most likely appear to happen all at one time right? In non blocking mode will I have to do a loop until all the data has been sent/received while adjusting the buffer pointer? p.s. I know that the packets may be received in any order, and that they won't all come in at the same time. I don't actually want to know what happens at this low of a level. I just want to know from a programmer's perspective. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 12:51 [ECOS] TCP/IP Stack packet regrouping Trenton D. Adams @ 2001-07-16 13:12 ` Grant Edwards 2001-07-16 13:20 ` Jonathan Larmour 1 sibling, 0 replies; 20+ messages in thread From: Grant Edwards @ 2001-07-16 13:12 UTC (permalink / raw) To: Trenton D. Adams; +Cc: eCos Discussion On Mon, Jul 16, 2001 at 01:51:55PM -0600, Trenton D. Adams wrote: > I'm curious as to what happens if I send 30K worth of data in one send? > Will it all send at one time? Probably not. If you're using Ethernet, only ~1500 bytes at a time can be sent. > What happens if I receive 30K of data, will it receive all 30K > at one time? Probably not. > If not, in blocking mode it will most likely appear to happen all at one > time right? Probably not. If you're using Ethernet, it will come in 1500 bytes at a time. > In non blocking mode will I have to do a loop until all the data has > been sent/received while adjusting the buffer pointer? Correct. You must do that in blocking mode also. > p.s. > I know that the packets may be received in any order, and that they > won't all come in at the same time. I don't actually want to know what > happens at this low of a level. I just want to know from a programmer's > perspective. From a programmer's perspective, TCP is a reliable stream of bytes. If you get the bytes, you will get the bytes in the right order with no corruption or duplication. The size of the chunks you get from read() is undefined. Some programs assume that a write of <1500 bytes will result in a corresponding read() of the same number of bytes. Those programs work on some platforms and networks and not on others. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 12:51 [ECOS] TCP/IP Stack packet regrouping Trenton D. Adams 2001-07-16 13:12 ` Grant Edwards @ 2001-07-16 13:20 ` Jonathan Larmour 2001-07-16 13:33 ` Trenton D. Adams 1 sibling, 1 reply; 20+ messages in thread From: Jonathan Larmour @ 2001-07-16 13:20 UTC (permalink / raw) To: Trenton D. Adams; +Cc: eCos Discussion "Trenton D. Adams" wrote: > > I'm curious as to what happens if I send 30K worth of data in one send? > Will it all send at one time? Not necessarily - it may depend on window size negotiation, fragmentation, MTUs etc. It _may_ send all at one time, but I wouldn't rely on it. At a high level it will all send, yes. > What happens if I receive 30K of data, will it receive all 30K at one > time? If you are sure that a single 30K TCP packet has been received, then yes, you should. But it's probably not portable to rely on it, and it's very difficult to be sure you would have received a single 30K packet. > If not, in blocking mode it will most likely appear to happen all at one > time right? Not necessarily. read() can return early if _some_ data is available. > In non blocking mode will I have to do a loop until all the data has > been sent/received while adjusting the buffer pointer? Yes. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 13:20 ` Jonathan Larmour @ 2001-07-16 13:33 ` Trenton D. Adams 2001-07-16 13:39 ` Gary Thomas ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Trenton D. Adams @ 2001-07-16 13:33 UTC (permalink / raw) To: 'Jonathan Larmour'; +Cc: 'eCos Discussion' > > > If not, in blocking mode it will most likely appear to > happen all at > > one time right? > > Not necessarily. read() can return early if _some_ data is > available. Are you saying that read () will return if ONLY some of the data is there, but will complete successfully if it's all there? So, to summarize what you said. Sending generally will send it all at once, and there's no need for a loop for the outgoing buffer? Receiving I should always do the loop just in case? ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 13:33 ` Trenton D. Adams @ 2001-07-16 13:39 ` Gary Thomas 2001-07-16 13:41 ` Trenton D. Adams 2001-07-16 13:45 ` Jonathan Larmour 2001-07-16 14:26 ` Grant Edwards 2 siblings, 1 reply; 20+ messages in thread From: Gary Thomas @ 2001-07-16 13:39 UTC (permalink / raw) To: Trenton D. Adams; +Cc: eCos Discussion On 16-Jul-2001 Trenton D. Adams wrote: > > > > > If not, in blocking mode it will most likely appear to > > happen all at > > > one time right? > > > > Not necessarily. read() can return early if _some_ data is > > available. > > Are you saying that read () will return if ONLY some of the data is > there, but will complete successfully if it's all there? > > > So, to summarize what you said. > > Sending generally will send it all at once, and there's no need for a > loop for the outgoing buffer? > Receiving I should always do the loop just in case? Yes, these comments are accurate, but only for TCP connections. Other types of connections will have completely different behaviour/semantics. ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 13:39 ` Gary Thomas @ 2001-07-16 13:41 ` Trenton D. Adams 0 siblings, 0 replies; 20+ messages in thread From: Trenton D. Adams @ 2001-07-16 13:41 UTC (permalink / raw) To: 'Gary Thomas'; +Cc: 'eCos Discussion' > On 16-Jul-2001 Trenton D. Adams wrote: > > > > > > > If not, in blocking mode it will most likely appear to > > > happen all at > > > > one time right? > > > > > > Not necessarily. read() can return early if _some_ data is > > > available. > > > > Are you saying that read () will return if ONLY some of > the data is > > there, but will complete successfully if it's all there? > > > > > > So, to summarize what you said. > > > > Sending generally will send it all at once, and there's > no need for a > > loop for the outgoing buffer? Receiving I should always > do the loop > > just in case? > > Yes, these comments are accurate, but only for TCP > connections. Other types of connections will have > completely different behaviour/semantics. > Thanks for that, I'm going to be using TCP! :) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 13:33 ` Trenton D. Adams 2001-07-16 13:39 ` Gary Thomas @ 2001-07-16 13:45 ` Jonathan Larmour 2001-07-16 14:26 ` Grant Edwards 2 siblings, 0 replies; 20+ messages in thread From: Jonathan Larmour @ 2001-07-16 13:45 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos Discussion' "Trenton D. Adams" wrote: > > > > > > If not, in blocking mode it will most likely appear to > > happen all at > > > one time right? > > > > Not necessarily. read() can return early if _some_ data is > > available. > > Are you saying that read () will return if ONLY some of the data is > there, but will complete successfully if it's all there? read() can return if some or all of the data is there. In both cases it will return the number of bytes actually read. > So, to summarize what you said. > > Sending generally will send it all at once, and there's no need for a > loop for the outgoing buffer? Yes. > Receiving I should always do the loop just in case? Yes. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 13:33 ` Trenton D. Adams 2001-07-16 13:39 ` Gary Thomas 2001-07-16 13:45 ` Jonathan Larmour @ 2001-07-16 14:26 ` Grant Edwards 2001-07-16 14:36 ` Jonathan Larmour 2001-07-16 14:44 ` Trenton D. Adams 2 siblings, 2 replies; 20+ messages in thread From: Grant Edwards @ 2001-07-16 14:26 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'Jonathan Larmour', 'eCos Discussion' On Mon, Jul 16, 2001 at 02:33:31PM -0600, Trenton D. Adams wrote: > > > > > If not, in blocking mode it will most likely appear to happen > > > all at one time right? > > > > Not necessarily. read() can return early if _some_ data is > > available. > > Are you saying that read () will return if ONLY some of the data is > there, but will complete successfully if it's all there? When you call read in blocking mode, it will return "n" when 1) there is some data available: n>0 2) there is an error: n<0 3) the connection has been closed: n==0 > So, to summarize what you said. > > Sending generally will send it all at once, and there's no need > for a loop for the outgoing buffer? No, that is not generally true. For small blocks, it will _usually_ be true. For large blocks of data, you will have to check the return value from write() in a loop. The values of "small" and "large" vary from platform to platform. > Receiving I should always do the loop just in case? Yes -- for both read and write. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 14:26 ` Grant Edwards @ 2001-07-16 14:36 ` Jonathan Larmour 2001-07-16 14:44 ` Trenton D. Adams 1 sibling, 0 replies; 20+ messages in thread From: Jonathan Larmour @ 2001-07-16 14:36 UTC (permalink / raw) To: Grant Edwards; +Cc: Trenton D. Adams, 'eCos Discussion' Grant Edwards wrote: > > > > Sending generally will send it all at once, and there's no need > > for a loop for the outgoing buffer? > > No, that is not generally true. For small blocks, it will > _usually_ be true. For large blocks of data, you will have to > check the return value from write() in a loop. The values of > "small" and "large" vary from platform to platform. Oops, yes you're right. I misremembered from the top of my head evidently. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 14:26 ` Grant Edwards 2001-07-16 14:36 ` Jonathan Larmour @ 2001-07-16 14:44 ` Trenton D. Adams 2001-07-16 15:09 ` Grant Edwards 2001-07-16 18:13 ` [ECOS] TCP/IP Stack packet regrouping Grant Edwards 1 sibling, 2 replies; 20+ messages in thread From: Trenton D. Adams @ 2001-07-16 14:44 UTC (permalink / raw) To: 'Grant Edwards' Cc: 'Jonathan Larmour', 'eCos Discussion', 'Gary Thomas' > On Mon, Jul 16, 2001 at 02:33:31PM -0600, Trenton D. Adams wrote: > > > > > > > If not, in blocking mode it will most likely appear > to happen > > > > all at one time right? > > > > > > Not necessarily. read() can return early if _some_ data is > > > available. > > > > Are you saying that read () will return if ONLY some of > the data is > > there, but will complete successfully if it's all there? > > When you call read in blocking mode, it will return "n" when > 1) there is some data available: n>0 > 2) there is an error: n<0 > 3) the connection has been closed: n==0 > > > So, to summarize what you said. > > > > Sending generally will send it all at once, and there's > no need for a > > loop for the outgoing buffer? > > No, that is not generally true. For small blocks, it will > _usually_ be true. For large blocks of data, you will have > to check the return value from write() in a loop. The > values of "small" and "large" vary from platform to platform. > Ok, who's actually correct here? Who's the one that wrote the TCP/IP stack? Are they listening? > > Receiving I should always do the loop just in case? > > Yes -- for both read and write. > I'm reading the Linux documentation on send (), and it says that a send () call will block if "the message does not fit into the send buffer of the socket". Which tells me it that it is sending the information all at once (from the programmer's perspective). It also says that if it's to big to pass through the underlying protocol, it will return with an error of EMSGSIZE. Is this correct or not? >> No, that is not generally true. For small blocks, it will _usually_ >> be true. For large blocks of data, you will have to check the return >> value from write() in a loop. The values of "small" and "large" vary >> from platform to platform. > Oops, yes you're right. I misremembered from the top of my head evidently. > >Jifl Did you actually misremember, or am I now screwing with your head? LOL How do I find out what the maximum message size is? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 14:44 ` Trenton D. Adams @ 2001-07-16 15:09 ` Grant Edwards 2001-07-16 15:32 ` Grant Edwards 2001-07-16 15:35 ` Trenton D. Adams 2001-07-16 18:13 ` [ECOS] TCP/IP Stack packet regrouping Grant Edwards 1 sibling, 2 replies; 20+ messages in thread From: Grant Edwards @ 2001-07-16 15:09 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Jonathan Larmour', 'eCos Discussion', 'Gary Thomas' On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote: > > > Sending generally will send it all at once, and there's no need > > > for a loop for the outgoing buffer? > > > > No, that is not generally true. For small blocks, it will > > _usually_ be true. For large blocks of data, you will have > > to check the return value from write() in a loop. The > > values of "small" and "large" vary from platform to platform. > > > > Ok, who's actually correct here? Who's the one that wrote the TCP/IP > stack? Are they listening? I didn't write it, but I'm reading it. :) In the eCos/BSD stack, it looks to me that send() is only "atomic" if the PR_ATOMIC flag is set in the protosw struct for the protocol associated with a socket. That flag isn't set for SOCK_STREAM. It is set for SOCK_DGRAM and SOCK_RAW. Of course, I could be misreading the code. But that does jibe with what I've always been told regarding checking the return value from a write() on a TCP socket. > I'm reading the Linux documentation on send (), and it says > that a send () call will block if "the message does not fit > into the send buffer of the socket". Which tells me it that it > is sending the information all at once (from the programmer's > perspective). It also says that if it's to big to pass through > the underlying protocol, it will return with an error of > EMSGSIZE. Is this correct or not? Good question. Linux's TCP stack is not derived from BSD sources, and it may behave differently. We can either start reading the source code or gen up a program that tries to write a huge block of data.... > > Oops, yes you're right. I misremembered from the top of my head > > evidently. > > Did you actually misremember, or am I now screwing with your head? LOL > > How do I find out what the maximum message size is? Another good question. :) -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 15:09 ` Grant Edwards @ 2001-07-16 15:32 ` Grant Edwards 2001-07-16 15:35 ` Trenton D. Adams 2001-07-16 15:35 ` Trenton D. Adams 1 sibling, 1 reply; 20+ messages in thread From: Grant Edwards @ 2001-07-16 15:32 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Jonathan Larmour', 'eCos Discussion', 'Gary Thomas' On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote: > I'm reading the Linux documentation on send (), and it says > that a send () call will block if "the message does not fit > into the send buffer of the socket". Which tells me it that it > is sending the information all at once (from the programmer's > perspective). It also says that if it's to big to pass through > the underlying protocol, it will return with an error of > EMSGSIZE. Is this correct or not? It does appear that a write on a TCP socket under Linux will block until all of the data is sent -- I tried a single write() with block sizes up to 16MB, and it blocked until all data was sent. However, if a signal comes along, the write() gets interrupted and it returns a partial value. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 15:32 ` Grant Edwards @ 2001-07-16 15:35 ` Trenton D. Adams 2001-07-16 17:36 ` Grant Edwards 0 siblings, 1 reply; 20+ messages in thread From: Trenton D. Adams @ 2001-07-16 15:35 UTC (permalink / raw) To: 'Grant Edwards'; +Cc: 'eCos Discussion' > On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote: > > > I'm reading the Linux documentation on send (), and it says > > that a send () call will block if "the message does not fit > > into the send buffer of the socket". Which tells me it that it > > is sending the information all at once (from the programmer's > > perspective). It also says that if it's to big to pass through > > the underlying protocol, it will return with an error of > > EMSGSIZE. Is this correct or not? > > It does appear that a write on a TCP socket under Linux will > block until all of the data is sent -- I tried a single write() > with block sizes up to 16MB, and it blocked until all data was > sent. However, if a signal comes along, the write() gets > interrupted and it returns a partial value. > You mean an OS signal like SIGHUP or something? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 15:35 ` Trenton D. Adams @ 2001-07-16 17:36 ` Grant Edwards 0 siblings, 0 replies; 20+ messages in thread From: Grant Edwards @ 2001-07-16 17:36 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos Discussion' On Mon, Jul 16, 2001 at 04:35:20PM -0600, Trenton D. Adams wrote: > > On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote: > > > > > I'm reading the Linux documentation on send (), and it says > > > that a send () call will block if "the message does not fit > > > into the send buffer of the socket". Which tells me it that it > > > is sending the information all at once (from the programmer's > > > perspective). It also says that if it's to big to pass through > > > the underlying protocol, it will return with an error of > > > EMSGSIZE. Is this correct or not? > > > > It does appear that a write on a TCP socket under Linux will > > block until all of the data is sent -- I tried a single write() > > with block sizes up to 16MB, and it blocked until all data was > > sent. However, if a signal comes along, the write() gets > > interrupted and it returns a partial value. > > > > You mean an OS signal like SIGHUP or something? Yes. I wrote a test program that did an alarm(1) [with a handler that did a printf()/return], and then did a write(s,buf,16*1024*1024). The write returned after about 800K bytes had been written. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 15:09 ` Grant Edwards 2001-07-16 15:32 ` Grant Edwards @ 2001-07-16 15:35 ` Trenton D. Adams 2001-07-16 17:43 ` Grant Edwards 1 sibling, 1 reply; 20+ messages in thread From: Trenton D. Adams @ 2001-07-16 15:35 UTC (permalink / raw) To: 'Grant Edwards' Cc: 'Jonathan Larmour', 'eCos Discussion', 'Gary Thomas' > > > > > Sending generally will send it all at once, and there's no need > > > > for a loop for the outgoing buffer? > > > > > > No, that is not generally true. For small blocks, it will > > > _usually_ be true. For large blocks of data, you will have > > > to check the return value from write() in a loop. The > > > values of "small" and "large" vary from platform to platform. > > > > > > > Ok, who's actually correct here? Who's the one that wrote the TCP/IP > > stack? Are they listening? > > I didn't write it, but I'm reading it. :) > > In the eCos/BSD stack, it looks to me that send() is only > "atomic" if the PR_ATOMIC flag is set in the protosw struct for > the protocol associated with a socket. That flag isn't set for > SOCK_STREAM. It is set for SOCK_DGRAM and SOCK_RAW. Of > course, I could be misreading the code. But that does jibe with > what I've always been told regarding checking the return value > from a write() on a TCP socket. > I THINK this is the opposite of the Linux version. The Linux TCP version is APPARENTLY atomic. I used to know what this means in computer terms, but I can't remember. Can you explain the ATOMIC thing to me? > > I'm reading the Linux documentation on send (), and it says > > that a send () call will block if "the message does not fit > > into the send buffer of the socket". Which tells me it that it > > is sending the information all at once (from the programmer's > > perspective). It also says that if it's to big to pass through > > the underlying protocol, it will return with an error of > > EMSGSIZE. Is this correct or not? > > Good question. > > Linux's TCP stack is not derived from BSD sources, and it may > behave differently. We can either start reading the source > code or gen up a program that tries to write a huge block of > data.... > Although it may not be derived from the sources, the docs say it "conforms to" 4.4BSD. Whether this just means the parameter list, or in fact the way it works as well, I don't know. > > > Oops, yes you're right. I misremembered from the top of my head > > > evidently. > > > > Did you actually misremember, or am I now screwing with your head? LOL > > > > How do I find out what the maximum message size is? > > Another good question. :) > I just looked, and it bases it on if_mtu if it's a broadcast packet. I don't understand the code below though because I don't know what ip_off or IP_DF are. I might look them up at a later time though. I'm primarily doing documentation/design for networking right now so I don't have time for this at the moment. if (ip->ip_off & IP_DF) { // Line 847 of ip_output.c error = EMSGSIZE; ipstat.ips_cantfrag++; goto bad; } len = (ifp->if_mtu - hlen) &~ 7; if (len < 8) { error = EMSGSIZE; goto bad; } ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 15:35 ` Trenton D. Adams @ 2001-07-16 17:43 ` Grant Edwards 2001-07-17 6:06 ` [ECOS] Simulation under CCS (Code Composer Studio) SEBASTIEN ANDRE 0 siblings, 1 reply; 20+ messages in thread From: Grant Edwards @ 2001-07-16 17:43 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Jonathan Larmour', 'eCos Discussion', 'Gary Thomas' On Mon, Jul 16, 2001 at 04:35:20PM -0600, Trenton D. Adams wrote: >>>>> Sending generally will send it all at once, and there's no >>>>>need for a loop for the outgoing buffer? >>> >>>> No, that is not generally true. For small blocks, it will >>>> _usually_ be true. For large blocks of data, you will have to >>>> check the return value from write() in a loop. The values of >>>> "small" and "large" vary from platform to platform. >>> >>> Ok, who's actually correct here? Who's the one that wrote the >>> TCP/IP stack? Are they listening? > >> I didn't write it, but I'm reading it. :) > >> In the eCos/BSD stack, it looks to me that send() is only >> "atomic" if the PR_ATOMIC flag is set in the protosw struct >> for the protocol associated with a socket. That flag isn't >> set for SOCK_STREAM. It is set for SOCK_DGRAM and SOCK_RAW. >> Of course, I could be misreading the code. But that does jibe >> with what I've always been told regarding checking the return >> value from a write() on a TCP socket. > > I THINK this is the opposite of the Linux version. The Linux > TCP version is APPARENTLY atomic. I used to know what this > means in computer terms, but I can't remember. Can you explain > the ATOMIC thing to me? I'm still not 100% sure that the eCos/BSD stack won't try to loop until all of the data is sent. I have a really tough time reading C code that's indented that way. I'm going to have to re-indent the eCos sources and study it some more. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* [ECOS] Simulation under CCS (Code Composer Studio) 2001-07-16 17:43 ` Grant Edwards @ 2001-07-17 6:06 ` SEBASTIEN ANDRE 0 siblings, 0 replies; 20+ messages in thread From: SEBASTIEN ANDRE @ 2001-07-17 6:06 UTC (permalink / raw) To: egcs; +Cc: 'eCos Discussion' [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 973 bytes --] Hi all, So i create a simple programm compiled for ARM without eCos KERNEL !! a base ARM code !! I can simulate it under GDB correctly but i can't simulate it with Code Composer Studio TMS470Rxx !! With time i find a way !! i must strip all information debug and after i can load under CCS !! But if i let some debug info the simulator hang !! (i try -ggdb, -gdwarf-2, etc ..) So the next step i had make it to try to load an eCos Program !! under GDB it load correctly and the entry point is the vector functions (the simaltion is not correct because thay are no hardware simulation but the code is correctly loaded) But with CCS i can't load it to !! if i strip information debug i have an internal error #5 !! i can't load it !! So what is wrong !!? CCS have a bug ? or i make a something wrong in the build process !!! ? I know this question is a CCS questions but i say it in this forums for the case of somebody know this tools !! best regards, Sébastien. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 14:44 ` Trenton D. Adams 2001-07-16 15:09 ` Grant Edwards @ 2001-07-16 18:13 ` Grant Edwards 2001-07-20 8:10 ` Trenton D. Adams 1 sibling, 1 reply; 20+ messages in thread From: Grant Edwards @ 2001-07-16 18:13 UTC (permalink / raw) To: Trenton D. Adams Cc: 'Jonathan Larmour', 'eCos Discussion', 'Gary Thomas' On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote: >> No, that is not generally true. For small blocks, it will >> _usually_ be true. For large blocks of data, you will have to >> check the return value from write() in a loop. The values of >> "small" and "large" vary from platform to platform. > > Ok, who's actually correct here? Who's the one that wrote the > TCP/IP stack? Are they listening? After reindenting uipc_socket.c and looking at it some more, it looks like the outer do/while loop in sosend() is waiting until all data has been sent (for a blocking, stream socket). The inner do/while loop fills up the so_snd buffer until it's full. After the inner loop has filled up the send buffer, the outer loop repeats the inner loop. There ought to be someplace in there where the task blocks waiting for more room in the send buffer, but I cant find it. But, the comment at the top of sosend() reads: * Returns nonzero on error, timeout or signal; callers * must check for short counts if EINTR/ERESTART are returned. * Data and control buffers are freed on return. If you can guarantee that no signals are going to happen, then you souldn't have to check for short counts. I don't like to depend on that assumption. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [ECOS] TCP/IP Stack packet regrouping 2001-07-16 18:13 ` [ECOS] TCP/IP Stack packet regrouping Grant Edwards @ 2001-07-20 8:10 ` Trenton D. Adams 2001-07-20 8:15 ` Jonathan Larmour 0 siblings, 1 reply; 20+ messages in thread From: Trenton D. Adams @ 2001-07-20 8:10 UTC (permalink / raw) To: grante Cc: 'Jonathan Larmour', 'eCos Discussion', 'Gary Thomas' > > On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote: > > >> No, that is not generally true. For small blocks, it will > >> _usually_ be true. For large blocks of data, you will have to > >> check the return value from write() in a loop. The values of > >> "small" and "large" vary from platform to platform. > > > > Ok, who's actually correct here? Who's the one that wrote the > > TCP/IP stack? Are they listening? > > After reindenting uipc_socket.c and looking at it some more, it > looks like the outer do/while loop in sosend() is waiting until > all data has been sent (for a blocking, stream socket). > > The inner do/while loop fills up the so_snd buffer until it's > full. After the inner loop has filled up the send buffer, the > outer loop repeats the inner loop. There ought to be someplace > in there where the task blocks waiting for more room in the > send buffer, but I cant find it. > > But, the comment at the top of sosend() reads: > > * Returns nonzero on error, timeout or signal; callers > * must check for short counts if EINTR/ERESTART are returned. > * Data and control buffers are freed on return. > > If you can guarantee that no signals are going to happen, then > you souldn't have to check for short counts. I don't like to > depend on that assumption. > I have now in fact tested eCos with a 40K string buffer. I used strcat () fill it with the same string + carriage returns over and over again. I then used send () which in fact did send the entire text buffer. So, you are correct. Now, about the signals thing! Can eCos applications receive signals like Linux does? If not, then I don't care because my code has no need to be portable to anything other than eCos. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [ECOS] TCP/IP Stack packet regrouping 2001-07-20 8:10 ` Trenton D. Adams @ 2001-07-20 8:15 ` Jonathan Larmour 0 siblings, 0 replies; 20+ messages in thread From: Jonathan Larmour @ 2001-07-20 8:15 UTC (permalink / raw) To: Trenton D. Adams; +Cc: 'eCos Discussion' "Trenton D. Adams" wrote: > > Now, about the signals thing! Can eCos applications receive signals > like Linux does? If not, then I don't care because my code has no need > to be portable to anything other than eCos. Only if you want it to in general, and certainly not if POSIX compatibility isn't included. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine Come to the Red Hat TechWorld open source conference in Brussels! Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/ ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2001-07-20 8:15 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-16 12:51 [ECOS] TCP/IP Stack packet regrouping Trenton D. Adams 2001-07-16 13:12 ` Grant Edwards 2001-07-16 13:20 ` Jonathan Larmour 2001-07-16 13:33 ` Trenton D. Adams 2001-07-16 13:39 ` Gary Thomas 2001-07-16 13:41 ` Trenton D. Adams 2001-07-16 13:45 ` Jonathan Larmour 2001-07-16 14:26 ` Grant Edwards 2001-07-16 14:36 ` Jonathan Larmour 2001-07-16 14:44 ` Trenton D. Adams 2001-07-16 15:09 ` Grant Edwards 2001-07-16 15:32 ` Grant Edwards 2001-07-16 15:35 ` Trenton D. Adams 2001-07-16 17:36 ` Grant Edwards 2001-07-16 15:35 ` Trenton D. Adams 2001-07-16 17:43 ` Grant Edwards 2001-07-17 6:06 ` [ECOS] Simulation under CCS (Code Composer Studio) SEBASTIEN ANDRE 2001-07-16 18:13 ` [ECOS] TCP/IP Stack packet regrouping Grant Edwards 2001-07-20 8:10 ` Trenton D. Adams 2001-07-20 8:15 ` Jonathan Larmour
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).