On 04/08/2011 04:14 PM, Doriano Blengino wrote:
>
> Perhaps I got it - but this should be confirmed by Benoit, I think.
>
> On the client side, you can receive a packet as a string. Then you can
> use a memory stream to read from the string, so the endianness is coped
> with by the stream object. I
On 04/08/2011 04:49 PM, Benoît Minisini wrote:
>> Kevin Fishburne wrote:
>>
>> Ahh, I understand a little better. I don't know much about endianness,
>> so please excuse my ignorance here.
>>
>> ...
>>
>> While it would be slow, I could just write functions for flipping the
>> byte order of charact
> Kevin Fishburne wrote:
>
> Ahh, I understand a little better. I don't know much about endianness,
> so please excuse my ignorance here.
>
> ...
>
> While it would be slow, I could just write functions for flipping the
> byte order of characters in a string. That would work fine for the
> client b
Il 08/04/2011 09:04, Kevin Fishburne ha scritto:
> On 04/08/2011 02:32 AM, Doriano Blengino wrote:
>
>>
>> Endiannes refers to the order the bytes are kept in memory, when a
>> numerical multi-byte value is involved. Strictly speaking, strings are
>> not affected. For example, human beings are
On 04/08/2011 02:32 AM, Doriano Blengino wrote:
> Kevin Fishburne ha scritto:
>>
>> Ahh, I understand a little better. I don't know much about endianness,
>> so please excuse my ignorance here. When reading socket data into a
>> string how is the data affected exactly? I can think of a few possibil
Kevin Fishburne ha scritto:
> On 04/07/2011 12:20 PM, Benoît Minisini wrote:
>
>> When you write the data to the socket, all data are converted from the CPU
>> endianness (little endian for Intel/AMD) to the network endianness (big
>> endian
>> by definition).
>>
>> When you read the data from
On 04/07/2011 12:20 PM, Benoît Minisini wrote:
>
> When you write the data to the socket, all data are converted from the CPU
> endianness (little endian for Intel/AMD) to the network endianness (big endian
> by definition).
>
> When you read the data from the socket, the data must be converted bac
> >
> > Because sockets are big endian, not little endian as the CPU. I think you
> > have to use READ to decode the messages as soon as you receive them.
> >
> > If you want to process them later, you can use a Variant[] to store the
> > decoded data instead of a String storing the undecoded dat
On 04/07/2011 05:05 AM, Benoît Minisini wrote:
>> On 04/05/2011 03:34 AM, Benoît Minisini wrote:
On 04/05/2011 01:39 AM, Kevin Fishburne wrote:
> Alright, I've transformed all the networking code to the suggested
> solution, and it's so close to working I can smell it. While there is
>
> On 04/05/2011 03:34 AM, Benoît Minisini wrote:
> >> On 04/05/2011 01:39 AM, Kevin Fishburne wrote:
> >>> Alright, I've transformed all the networking code to the suggested
> >>> solution, and it's so close to working I can smell it. While there is
> >>> more code now, I like it better as it's eas
On 04/05/2011 03:34 AM, Benoît Minisini wrote:
>> On 04/05/2011 01:39 AM, Kevin Fishburne wrote:
>>> Alright, I've transformed all the networking code to the suggested
>>> solution, and it's so close to working I can smell it. While there is
>>> more code now, I like it better as it's easier to rea
On 04/05/2011 03:54 AM, Kevin Fishburne wrote:
> http://www.youtube.com/watch?v=cJPa8dGBxfM
>
> I'll get back to you in the morning if it's still not working. Damn..
Works. Thank you.
--
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sa...@eightvirtues.com
phone: (770)
On 04/05/2011 03:34 AM, Benoît Minisini wrote:
>
> Not strange if you read the doc carefully. :-)
>
> When using "WRITE #Stream, AString As String", the length of the string is
> always written before the string contents.
>
> To just write the string contents, you must use the second syntax of WRIT
> On 04/05/2011 01:39 AM, Kevin Fishburne wrote:
> > Alright, I've transformed all the networking code to the suggested
> > solution, and it's so close to working I can smell it. While there is
> > more code now, I like it better as it's easier to read (important!).
> >
> > Some code:
> > Dim
On 04/05/2011 01:39 AM, Kevin Fishburne wrote:
Alright, I've transformed all the networking code to the suggested
solution, and it's so close to working I can smell it. While there is
more code now, I like it better as it's easier to read (important!).
Some code:
Dim id As Byte
Dim type
On 04/04/2011 02:44 PM, Kevin Fishburne wrote:
> On 04/04/2011 04:20 AM, Benoît Minisini wrote:
>>
>> You should better decode the packet directly with READ instructions.
>
> I would except the incoming transactions aren't processed immediately.
> They are stored in sequence by ID in a transaction
On 04/04/2011 04:20 AM, Benoît Minisini wrote:
>> Excellent, that's an elegant solution. Thanks! Is it possible to read
>> one or more values from the beginning of the packet normally, then read
>> the remaining data into a single string? Something like this:
>>
>> Public Sub UDP_Read()
>>
>> D
> Excellent, that's an elegant solution. Thanks! Is it possible to read
> one or more values from the beginning of the packet normally, then read
> the remaining data into a single string? Something like this:
>
> Public Sub UDP_Read()
>
>Dim id As Byte
>Dim type As Byte
>Dim data As
On 04/03/2011 08:46 PM, Benoît Minisini wrote:
> Finally I come with a solution. Well I hope.
>
> I added three new methods to the Stream class (and so to its child classes:
> File, Socket, UdpSocket...) in revision #3730.
>
> Stream.Begin(), Stream.Send() and Stream.Drop().
>
> All WRITE instructi
> I'm finding that the task of replacing the Mk$ functions with structures
> for UDP packet client/server transactions is a massive undertaking. So
> far it's affecting every part of my project that constructs, parses,
> sends and receives data. As a consequence the network code is going from
> doz
Il 03/04/2011 22:07, Kevin Fishburne ha scritto:
> On 04/03/2011 02:27 PM, Benoît Minisini wrote:
>
>> OK... I should have read all that more carefully, as I have said rubbish.
>>
>> Sending a message to an UDP socket can only be done with a string or a
>> structure. If you use several WRITE in
On 04/03/2011 09:33 AM, Jussi Lahtinen wrote:
>> With respect to Doriano, how would one use the memcpy() statement in
>> GAMBAS? I see from Wikipedia that "void *memcpy(void *dest, const void
>> *src, size_t n);" shows the syntax in C. My two questions are, how do
>> you call external library funct
On 04/03/2011 02:27 PM, Benoît Minisini wrote:
>
> OK... I should have read all that more carefully, as I have said rubbish.
>
> Sending a message to an UDP socket can only be done with a string or a
> structure. If you use several WRITE instructions, you will get one message by
> WRITE. Not a good
> > I'm finding that the task of replacing the Mk$ functions with structures
> > for UDP packet client/server transactions is a massive undertaking. So
> > far it's affecting every part of my project that constructs, parses,
> > sends and receives data. As a consequence the network code is going fr
Il 03/04/2011 15:33, Jussi Lahtinen ha scritto:
>> With respect to Doriano, how would one use the memcpy() statement in
>> GAMBAS? I see from Wikipedia that "void *memcpy(void *dest, const void
>> *src, size_t n);" shows the syntax in C. My two questions are, how do
>> you call external library fun
> With respect to Doriano, how would one use the memcpy() statement in
> GAMBAS? I see from Wikipedia that "void *memcpy(void *dest, const void
> *src, size_t n);" shows the syntax in C. My two questions are, how do
> you call external library functions in gb, and how would you translate
> the C sy
> On 04/01/2011 05:24 AM, Benoît Minisini wrote:
> > Using a structure just allow you to directly use the READ/WRITE
> > instruction because they have a build-in serialization support. But as
> > you noticed, handling a lot of different structures is not handy!
>
> Yes, because I need to keep a tr
On 04/01/2011 05:24 AM, Benoît Minisini wrote:
> Using a structure just allow you to directly use the READ/WRITE instruction
> because they have a build-in serialization support. But as you noticed,
> handling a lot of different structures is not handy!
Yes, because I need to keep a transaction hi
>
> Another stab in the dark: could you have a Object array, and then an
> class for each
> type of message which knows how to pack and unpack itself to the wire
> using an internal
> structure
>
> Ian
>
Yes!
--
Benoît Minisini
> I'm finding that the task of replacing the Mk$ functions with structures
> for UDP packet client/server transactions is a massive undertaking. So
> far it's affecting every part of my project that constructs, parses,
> sends and receives data. As a consequence the network code is going from
> doz
On 04/01/2011 04:12 AM, Doriano Blengino wrote:
> If I were Benoit, I would have leaved those mkxxx in place, neglecting
> the agnosticism.They were dirty things time ago; they still would be
> dirty things; nobody is perfect; if you don't like them, don't use them.
They are "dirty". I proposed wr
Kevin Fishburne ha scritto:
> On 04/01/2011 01:15 AM, Bruce Bruen wrote:
>
>> On Friday, April 01, 2011 01:17:50 PM Kevin Fishburne wrote:
>>
>>> I'm finding that the task of replacing the Mk$ functions with structures
>>> for UDP packet client/server transactions is a massive undertaking.
On Fri, Apr 1, 2011 at 4:36 PM, Kevin Fishburne
wrote:
> On 04/01/2011 01:15 AM, Bruce Bruen wrote:
>> On Friday, April 01, 2011 01:17:50 PM Kevin Fishburne wrote:
>>> I'm finding that the task of replacing the Mk$ functions with structures
>>> for UDP packet client/server transactions is a massiv
On 04/01/2011 01:15 AM, Bruce Bruen wrote:
> On Friday, April 01, 2011 01:17:50 PM Kevin Fishburne wrote:
>> I'm finding that the task of replacing the Mk$ functions with structures
>> for UDP packet client/server transactions is a massive undertaking. So
>> far it's affecting every part of my proj
On Friday, April 01, 2011 01:17:50 PM Kevin Fishburne wrote:
> I'm finding that the task of replacing the Mk$ functions with structures
> for UDP packet client/server transactions is a massive undertaking. So
> far it's affecting every part of my project that constructs, parses,
> sends and receive
Ok Kevin, new to me that is a game. I have read an notified your comprehends
Nevertheless, if you want me to, let me take a part of your
Gambas-Experiences, they might be good for both of us.
regards, Dag-Jarle
2011/4/1 Kevin Fishburne
> On 04/01/2011 12:17 AM, Dag-Jarle Johansen wrote:
> > Kev
On 04/01/2011 12:17 AM, Dag-Jarle Johansen wrote:
> Kevin, I have no idea. But in lack of business and money enough to live for,
> I would like to help you, if I am a good enough programmer. I have NOT made
> programs in your kind until now; my kind of networking was just to have the
> right client
Kevin, I have no idea. But in lack of business and money enough to live for,
I would like to help you, if I am a good enough programmer. I have NOT made
programs in your kind until now; my kind of networking was just to have the
right client idle or not.
IF you want me to, I would like to spend so
I'm finding that the task of replacing the Mk$ functions with structures
for UDP packet client/server transactions is a massive undertaking. So
far it's affecting every part of my project that constructs, parses,
sends and receives data. As a consequence the network code is going from
dozens of
39 matches
Mail list logo
