Hi bbracken and other guys,
I just took a detail review for the current TCPUpdate. (Last week I just moved to other projects, back again,hehe)
There are still several points I am not very sure after I compared them with UDP updating message through wireshark.
1, "baseaddr" and "length" after "102 Starting update"
==> , baseaddr is "FF C0 80 00" and lenght is "00 03 1d 04". Are they fixed value or I must calculate them myself?
2, In UDP method, the app is split into pieces which have their own baseaddr and lenth, in TCPUpdate, from the coding, It looks enough I just write the app in one time, isn't?
3, When I use Ultra Edit to open a *.s19, there are many "S315020000x" as heads, It looks some sequence number for the whole app. Do I need to care about them when I write the app to the socket? Or should I splite them based on these number and then write them into the socket?
Best regards,
Yang
continue for remotely updating Netburner :)
Re: continue for remotely updating Netburner :)
Yang,
I'm not exactly sure what you are tyring to do? If you are running from a PC, the simplest thing seems to spawn TCPUpdate from within your app. Specify the filename and target and away you go. If you are trying to embed the C code in an app, I would suggest "borrowing" as much of the TCPUpdate code that you can. I'm not an expert on the internals of how the two update programs work. That's the nice thing about NetBurner... you don't have to be a "rocket scientist" to use the stuff.
bb
I'm not exactly sure what you are tyring to do? If you are running from a PC, the simplest thing seems to spawn TCPUpdate from within your app. Specify the filename and target and away you go. If you are trying to embed the C code in an app, I would suggest "borrowing" as much of the TCPUpdate code that you can. I'm not an expert on the internals of how the two update programs work. That's the nice thing about NetBurner... you don't have to be a "rocket scientist" to use the stuff.
bb
Re: continue for remotely updating Netburner :)
bbracken wrote:Yang,
I'm not exactly sure what you are tyring to do? If you are running from a PC, the simplest thing seems to spawn TCPUpdate from within your app. Specify the filename and target and away you go. If you are trying to embed the C code in an app, I would suggest "borrowing" as much of the TCPUpdate code that you can. I'm not an expert on the internals of how the two update programs work. That's the nice thing about NetBurner... you don't have to be a "rocket scientist" to use the stuff.
bb
Hi bbracken,
Ah, there needed more explaination from me.
I need to write down one applicaton to work with TCPUpdate to do the updating. TCPUpate is at Netburner, and my application is at DC which is the remote side. To my understanding, TCPUpdate is like Autoupdate. NNDK uses UDP to contact with AuotUpdate. I want to use my app to contact with TCPUpdate.
In TCPUpdate, some parameters in messages are actually checked like AutoUpdate dose. I want to undertand how to accurately encode them.
In our DC, there is no way to run NNDK, so a new application looks have to be created for the similiar role like NNDK when playing updating.
Regards,
Yang
Regards,
Yang
Re: continue for remotely updating Netburner :)
Hell guys, there is the solution for the issue. I should have explained the whole thing more clearly.
To share with you.
> [lgitlitz - Wed Sep 30 18:51:20 2009]:
>
> Hi,
>
> This gives me a much better idea of what your situation is... I put my
> responses under your comments.
>
> > [Enex - Wed Sep 30 17:43:03 2009]:
> >
> > Hello,
> >
> > I think may I use another way to ask, hehe. If any points should be
> > modified, please don't hesitate.
> >
> > Based on the truth:
> > 1, there is TCPUpdate task which can be added in Netburner.
>
> Yes, done by replacing EnableAutoUpdate with int StartTcpUpdate( int
> priority ); in your NetBurner application.
>
> > 2, there is TcpUpdate.exe in Windows matched.
>
> Correct
> Windows executable: C:\nburn\pcbin\TcpUpdate.exe
> Source: C:\nburn\pctools\tcpupdate
>
> >
> > If above two points are not correct, below is just crab and can be
> > ignored.
> >
> > Q: Is it correct that TCPUpdate task in Netburner first "listen"
the
> > request from anywhere.
> > A: Yes.
> >
> > Q: Does TcpUpdate.exe start the updating by firstl asking Netburner
to
> > setup TCP connection?
> > A: Yes.
> >
> > Q: If Netbuner is sitting behind some firewall, but TcpUpdate.exe
is at
> > such as public network. Can the tcp connection be set up?
> > A: I think No. Firewall will stop any initial request from outside.
>
> If the firewall blocks all external requests then this is true. If
you
> have access to the firewall settings then you can allow the NetBurner
> TCP port (20034) for the NetBurner IP. If you can not modify the
> firewall settings then you have a more difficult problem.
> Does this firewall allow making outgoing connections on all ports? If
> yes then you might want to modify C:\nburn\system\tcpupdate.cpp so the
> task will attempt to make an outgoing connection to the server every
set
> time period, say once a day. Keep in mind you will need to make a
> custom TCPUpdate application that allows incomming connections for
this
> to work. The NetBurner side of the code can be done by changing the
> line "int sr = accept( sl, &client_addr, &port, 0 );". Remove the 0
and
> add timeout value... ( TICKS_PER_SECOND * 60 * 60 * 24 ) this should
be
> a full day. When this function returns check to see if it is = to
> TCP_ERR_TIMEOUT or -1. This would mean you timed out and it has been
a
> full day, then try to make an outgoing connection to the server with
the
> custom TCPUpdate server application.
>
> >
> > Q: Can TcpUpdate.exe be run on linux platform?
> > A: I think No.
>
> No, this is a windows executable. If your server was a window PC then
> you could use the command line to TCPUpdate a module. For example,
say
> you have a NetBurner at IP 10.1.1.1 and you want to load foo_APP.s19
> your PC application can call:
> TcpUpdate.exe -I10.1.1.1 -Ffoo_APP.s19 -R -A
>
> It sounds like you want the NetBurner to make an outgoing connection
to
> your server, then checks its status, then updates if necessary. Due
to
> these complexities you will probably want to integrate the TCPUpdate
> functionality into your application. The core updating functionality
of
> the PC application if found in the following file:
> C:\nburn\pctools\tcpupdate\updatedlg.cpp
>
> >
> > Let's first clarify above points, hehe. No worry
> >
> > Regards,
> > Yang
> >
> >
>
> Let me know if anything else need more clarification.
>
> -Larry
Hello Larry,
Yes, that what we want to do.
As for the firewall, because in the furture, it could be very dynamic,
but at least, we know it should permit TCP connection launched from
inside.
Our scenaio at the moment is: heartbeat every certain time is used
between our Data Centre and Netburner. Data Center can use these
heartbeats to monitor Netburner's status and also use the response
message to notice Netburner if any updating.
When Netburner receive this notice, it will trigger the update. I will
use TCPUpdate task, but the talking method must be changed just as you
expect. It will launch TCP connection to Data Center.
One app in Data Centre will listen any updating requiry and do the
updating.
It's very happy that you tell me the souce code about TcpUpdate.exe. I
thought there might be no souce code. From the other side, may I should
have reviewed the Netburner development guide more detaily.
Now I need to jump into those souce code. I want to use Perl to
implement it since I just guess Perl may be easier for cross-platform.
But for the cross-platform, to be frank, I am lack of experience.
Thank you very much. The correct direction you give me is so important.
Regards,
Yang
To share with you.
> [lgitlitz - Wed Sep 30 18:51:20 2009]:
>
> Hi,
>
> This gives me a much better idea of what your situation is... I put my
> responses under your comments.
>
> > [Enex - Wed Sep 30 17:43:03 2009]:
> >
> > Hello,
> >
> > I think may I use another way to ask, hehe. If any points should be
> > modified, please don't hesitate.
> >
> > Based on the truth:
> > 1, there is TCPUpdate task which can be added in Netburner.
>
> Yes, done by replacing EnableAutoUpdate with int StartTcpUpdate( int
> priority ); in your NetBurner application.
>
> > 2, there is TcpUpdate.exe in Windows matched.
>
> Correct
> Windows executable: C:\nburn\pcbin\TcpUpdate.exe
> Source: C:\nburn\pctools\tcpupdate
>
> >
> > If above two points are not correct, below is just crab and can be
> > ignored.
> >
> > Q: Is it correct that TCPUpdate task in Netburner first "listen"
the
> > request from anywhere.
> > A: Yes.
> >
> > Q: Does TcpUpdate.exe start the updating by firstl asking Netburner
to
> > setup TCP connection?
> > A: Yes.
> >
> > Q: If Netbuner is sitting behind some firewall, but TcpUpdate.exe
is at
> > such as public network. Can the tcp connection be set up?
> > A: I think No. Firewall will stop any initial request from outside.
>
> If the firewall blocks all external requests then this is true. If
you
> have access to the firewall settings then you can allow the NetBurner
> TCP port (20034) for the NetBurner IP. If you can not modify the
> firewall settings then you have a more difficult problem.
> Does this firewall allow making outgoing connections on all ports? If
> yes then you might want to modify C:\nburn\system\tcpupdate.cpp so the
> task will attempt to make an outgoing connection to the server every
set
> time period, say once a day. Keep in mind you will need to make a
> custom TCPUpdate application that allows incomming connections for
this
> to work. The NetBurner side of the code can be done by changing the
> line "int sr = accept( sl, &client_addr, &port, 0 );". Remove the 0
and
> add timeout value... ( TICKS_PER_SECOND * 60 * 60 * 24 ) this should
be
> a full day. When this function returns check to see if it is = to
> TCP_ERR_TIMEOUT or -1. This would mean you timed out and it has been
a
> full day, then try to make an outgoing connection to the server with
the
> custom TCPUpdate server application.
>
> >
> > Q: Can TcpUpdate.exe be run on linux platform?
> > A: I think No.
>
> No, this is a windows executable. If your server was a window PC then
> you could use the command line to TCPUpdate a module. For example,
say
> you have a NetBurner at IP 10.1.1.1 and you want to load foo_APP.s19
> your PC application can call:
> TcpUpdate.exe -I10.1.1.1 -Ffoo_APP.s19 -R -A
>
> It sounds like you want the NetBurner to make an outgoing connection
to
> your server, then checks its status, then updates if necessary. Due
to
> these complexities you will probably want to integrate the TCPUpdate
> functionality into your application. The core updating functionality
of
> the PC application if found in the following file:
> C:\nburn\pctools\tcpupdate\updatedlg.cpp
>
> >
> > Let's first clarify above points, hehe. No worry
> >
> > Regards,
> > Yang
> >
> >
>
> Let me know if anything else need more clarification.
>
> -Larry
Hello Larry,
Yes, that what we want to do.
As for the firewall, because in the furture, it could be very dynamic,
but at least, we know it should permit TCP connection launched from
inside.
Our scenaio at the moment is: heartbeat every certain time is used
between our Data Centre and Netburner. Data Center can use these
heartbeats to monitor Netburner's status and also use the response
message to notice Netburner if any updating.
When Netburner receive this notice, it will trigger the update. I will
use TCPUpdate task, but the talking method must be changed just as you
expect. It will launch TCP connection to Data Center.
One app in Data Centre will listen any updating requiry and do the
updating.
It's very happy that you tell me the souce code about TcpUpdate.exe. I
thought there might be no souce code. From the other side, may I should
have reviewed the Netburner development guide more detaily.
Now I need to jump into those souce code. I want to use Perl to
implement it since I just guess Perl may be easier for cross-platform.
But for the cross-platform, to be frank, I am lack of experience.
Thank you very much. The correct direction you give me is so important.
Regards,
Yang