Maximum buffer

[pietry <pi...@death-squad.ro>]

I tried to increase the mina buffer sizes ( both receive and send) but this
still has no success. I always get the same exception : 
buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954
(Hexdump: empty)
Used this getSessionConfig().setReceiveBufferSize();
and getSessionConfig().setSendBufferSize();
Any suggestions ?
-- 
View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14360017.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: Maximum buffer

[Bogdan Ciprian Pistol <bo...@gmail.com>]

Hi Jeroen and pietry,

TCP guarantees that the packets will be in the same order, that it
will retransmit the lost packets and discard duplicates.
You don't need to worry about all the above in your MINA based
application because you are at a level above TCP, you are not
implementing TCP, TCP does all this for you.
You are too worried about how routing is done. You don't need to know
this. TCP is a connection oriented protocol, if you are above the TCP
layer then you deal with connections (sockets, etc),
you shouldn't care what path a router chooses or other TCP guaranteed stuff.

On Dec 16, 2007 6:03 PM, Jeroen Brattinga <je...@gmail.com> wrote:
> You have to take these (strange) situations in consideration, and decide
> what action to take. It could be that you discard a previous session if
> you receive conflicting information.
>
> Remember that the 'conversations' (= the protocol communications) you
> have will not always be ideal. Sometimes you get corrupt information,
> sometimes the connection is dropped without any warning (or exit
> message!). In these situations you can easily get conflicting messages.
>
> An example: someone connects to a server. The server receives a connect
> message and keeps track of the client. It expects a disconnect message
> when the client disconnects. But what if the client is terminated before
> it can send this message? How long is the server going to wait for the
> client? What happens if the client tries to reconnect ... the old
> session is still active on the server...
>
> Oh, and packet routing is totally independent of both clients. Every
> router along the way decides what path each packet is going to take.
> This means that you are never sure about the route of each packet. In a
> LAN situation, this is of course much easier (since the routing choices
> are limited), but on the internet it's a whole different matter.
>
> A connection between two peers is often simplified as a straight line.
> In reality that is always never the case; if you would draw the routes
> each packet takes, it would look more like a mesh than a line.
>
>
> Jeroen Brattinga
>
>
> On Sun, 2007-12-16 at 07:40 -0800, pietry wrote:
> > I'm implementing the ADC protocol.
> > http://dcplusplus.sf.net/ADC.html
> >
> > The info received by any client is what happens to other client, which is
> > independent to current client.
> > In other words, the client receives for example notifications when somebody
> > enters or exits.
> > If somebody reconnects and the package of connection arrives before the one
> > of exiting, then the client receives like : "another client with the same
> > name connected, how is that possible now i have two of them "
> > If a connection between two peers is made once, why package X would be
> > routed through China and Y through Africa...
> >
> >
> >
> > Jeroen Brattinga wrote:
> > >
> > > What you're talking about takes place at a lower level. As an example,
> > > say you are sending a 5Kb payload (a couple of lines of text, for
> > > instance).
> > >
> > > This 5Kb is split up in packets; each one gets the right header and
> > > checksum and is sent to their destination. There the TCP layer assembles
> > > the separate packets, puts them in the right order and eventually passes
> > > the data to the application. In the end you'll see the 5Kb; nicely
> > > assembled in the proper order.
> > >
> > > This has nothing to do with the level you're talking about: the protocol
> > > level. You have to do the order and status housekeeping for your
> > > protocol. You could adding a unique ID to each message to do that. If
> > > you can't see how that's possible, try sharing some of the details of
> > > your protocol, maybe someone on this list has an idea.
> > >
> > > By the way, it might be a good idea to read up on the OSI model
> > > (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the
> > > difference between the transport layer (TCP) and the application layer
> > > (where your protocol functions).
> > >
> > >
>
> -snip-
>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> > >
> >
>
>

Re: Maximum buffer

[Jeroen Brattinga <je...@gmail.com>]

You have to take these (strange) situations in consideration, and decide
what action to take. It could be that you discard a previous session if
you receive conflicting information. 

Remember that the 'conversations' (= the protocol communications) you
have will not always be ideal. Sometimes you get corrupt information,
sometimes the connection is dropped without any warning (or exit
message!). In these situations you can easily get conflicting messages.

An example: someone connects to a server. The server receives a connect
message and keeps track of the client. It expects a disconnect message
when the client disconnects. But what if the client is terminated before
it can send this message? How long is the server going to wait for the
client? What happens if the client tries to reconnect ... the old
session is still active on the server...

Oh, and packet routing is totally independent of both clients. Every
router along the way decides what path each packet is going to take.
This means that you are never sure about the route of each packet. In a
LAN situation, this is of course much easier (since the routing choices
are limited), but on the internet it's a whole different matter.

A connection between two peers is often simplified as a straight line.
In reality that is always never the case; if you would draw the routes
each packet takes, it would look more like a mesh than a line.


Jeroen Brattinga

On Sun, 2007-12-16 at 07:40 -0800, pietry wrote:
> I'm implementing the ADC protocol.
> http://dcplusplus.sf.net/ADC.html
> 
> The info received by any client is what happens to other client, which is
> independent to current client.
> In other words, the client receives for example notifications when somebody
> enters or exits.
> If somebody reconnects and the package of connection arrives before the one
> of exiting, then the client receives like : "another client with the same
> name connected, how is that possible now i have two of them "
> If a connection between two peers is made once, why package X would be
> routed through China and Y through Africa...
> 
> 
> 
> Jeroen Brattinga wrote:
> > 
> > What you're talking about takes place at a lower level. As an example,
> > say you are sending a 5Kb payload (a couple of lines of text, for
> > instance). 
> > 
> > This 5Kb is split up in packets; each one gets the right header and
> > checksum and is sent to their destination. There the TCP layer assembles
> > the separate packets, puts them in the right order and eventually passes
> > the data to the application. In the end you'll see the 5Kb; nicely
> > assembled in the proper order.
> > 
> > This has nothing to do with the level you're talking about: the protocol
> > level. You have to do the order and status housekeeping for your
> > protocol. You could adding a unique ID to each message to do that. If
> > you can't see how that's possible, try sharing some of the details of
> > your protocol, maybe someone on this list has an idea.
> > 
> > By the way, it might be a good idea to read up on the OSI model
> > (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the
> > difference between the transport layer (TCP) and the application layer
> > (where your protocol functions).
> > 
> > 

-snip-

> >> >> 
> >> > 
> >> > 
> >> > 
> >> 
> > 
> > 
> > 
> 

Re: Maximum buffer

[pietry <pi...@death-squad.ro>]

I'm implementing the ADC protocol.
http://dcplusplus.sf.net/ADC.html

The info received by any client is what happens to other client, which is
independent to current client.
In other words, the client receives for example notifications when somebody
enters or exits.
If somebody reconnects and the package of connection arrives before the one
of exiting, then the client receives like : "another client with the same
name connected, how is that possible now i have two of them "
If a connection between two peers is made once, why package X would be
routed through China and Y through Africa...



Jeroen Brattinga wrote:
> 
> What you're talking about takes place at a lower level. As an example,
> say you are sending a 5Kb payload (a couple of lines of text, for
> instance). 
> 
> This 5Kb is split up in packets; each one gets the right header and
> checksum and is sent to their destination. There the TCP layer assembles
> the separate packets, puts them in the right order and eventually passes
> the data to the application. In the end you'll see the 5Kb; nicely
> assembled in the proper order.
> 
> This has nothing to do with the level you're talking about: the protocol
> level. You have to do the order and status housekeeping for your
> protocol. You could adding a unique ID to each message to do that. If
> you can't see how that's possible, try sharing some of the details of
> your protocol, maybe someone on this list has an idea.
> 
> By the way, it might be a good idea to read up on the OSI model
> (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the
> difference between the transport layer (TCP) and the application layer
> (where your protocol functions).
> 
> 
> Jeroen Brattinga
> 
> On Sun, 2007-12-16 at 03:58 -0800, pietry wrote:
>> Shouldnt the TCP/IP protocol handle this? The TCP specs say that it makes
>> sure all packets are delivered, no losses and no misorder...
>> 
>> The protocol can't be implemented response-based so there is nothing i
>> can
>> do in this matter.. hoped there would be a way to make sure the packets
>> are
>> received ok...
>> 
>> 
>> Jeroen Brattinga wrote:
>> > 
>> > That's common in TCP (and UDP) communications. Since you never really
>> > know how a packet is routed (one could be routed through Japan, the
>> next
>> > through Russia, for instance), the order is something you have to keep
>> > track of. 
>> > 
>> > There are various ways to implement this (e.g. don't send a packet
>> > before you have received a packet), and it's one of the main things you
>> > have to keep in mind when implementing any network protocol!
>> > 
>> > 
>> > Jeroen Brattinga
>> > 
>> > On Sun, 2007-12-16 at 03:04 -0800, pietry wrote:
>> >> It works, thanks a lot :)
>> >> 
>> >> I also have another problem with TCP packages.. it seems that
>> sometimes
>> >> they
>> >> reach in different order then i wrote to the Sessions. My question is
>> :
>> >> is
>> >> this possible to be because of MINA or the settings i had to my
>> server?
>> >> Or
>> >> it's a bug in my code ?
>> >> 
>> >> 
>> >> 
>> >> Jeroen Brattinga wrote:
>> >> > 
>> >> > You're propable using the TextLineDecoder? Then you have to set the
>> >> > maximum line length property (which defaults to 1KB). Use the
>> >> > setMaxLineLength method to do this.
>> >> > 
>> >> > Jeroen Brattinga
>> >> > 
>> >> > 
>> >> > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote:
>> >> >> I tried to increase the mina buffer sizes ( both receive and send)
>> but
>> >> >> this
>> >> >> still has no success. I always get the same exception : 
>> >> >> buffer.org.apache.mina.common.BufferDataException: Line is too
>> long:
>> >> 2954
>> >> >> (Hexdump: empty)
>> >> >> Used this getSessionConfig().setReceiveBufferSize();
>> >> >> and getSessionConfig().setSendBufferSize();
>> >> >> Any suggestions ?
>> >> > 
>> >> > 
>> >> > 
>> >> 
>> > 
>> > 
>> > 
>> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14362619.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: Maximum buffer

[Jeroen Brattinga <je...@gmail.com>]

What you're talking about takes place at a lower level. As an example,
say you are sending a 5Kb payload (a couple of lines of text, for
instance). 

This 5Kb is split up in packets; each one gets the right header and
checksum and is sent to their destination. There the TCP layer assembles
the separate packets, puts them in the right order and eventually passes
the data to the application. In the end you'll see the 5Kb; nicely
assembled in the proper order.

This has nothing to do with the level you're talking about: the protocol
level. You have to do the order and status housekeeping for your
protocol. You could adding a unique ID to each message to do that. If
you can't see how that's possible, try sharing some of the details of
your protocol, maybe someone on this list has an idea.

By the way, it might be a good idea to read up on the OSI model
(http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the
difference between the transport layer (TCP) and the application layer
(where your protocol functions).


Jeroen Brattinga

On Sun, 2007-12-16 at 03:58 -0800, pietry wrote:
> Shouldnt the TCP/IP protocol handle this? The TCP specs say that it makes
> sure all packets are delivered, no losses and no misorder...
> 
> The protocol can't be implemented response-based so there is nothing i can
> do in this matter.. hoped there would be a way to make sure the packets are
> received ok...
> 
> 
> Jeroen Brattinga wrote:
> > 
> > That's common in TCP (and UDP) communications. Since you never really
> > know how a packet is routed (one could be routed through Japan, the next
> > through Russia, for instance), the order is something you have to keep
> > track of. 
> > 
> > There are various ways to implement this (e.g. don't send a packet
> > before you have received a packet), and it's one of the main things you
> > have to keep in mind when implementing any network protocol!
> > 
> > 
> > Jeroen Brattinga
> > 
> > On Sun, 2007-12-16 at 03:04 -0800, pietry wrote:
> >> It works, thanks a lot :)
> >> 
> >> I also have another problem with TCP packages.. it seems that sometimes
> >> they
> >> reach in different order then i wrote to the Sessions. My question is :
> >> is
> >> this possible to be because of MINA or the settings i had to my server?
> >> Or
> >> it's a bug in my code ?
> >> 
> >> 
> >> 
> >> Jeroen Brattinga wrote:
> >> > 
> >> > You're propable using the TextLineDecoder? Then you have to set the
> >> > maximum line length property (which defaults to 1KB). Use the
> >> > setMaxLineLength method to do this.
> >> > 
> >> > Jeroen Brattinga
> >> > 
> >> > 
> >> > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote:
> >> >> I tried to increase the mina buffer sizes ( both receive and send) but
> >> >> this
> >> >> still has no success. I always get the same exception : 
> >> >> buffer.org.apache.mina.common.BufferDataException: Line is too long:
> >> 2954
> >> >> (Hexdump: empty)
> >> >> Used this getSessionConfig().setReceiveBufferSize();
> >> >> and getSessionConfig().setSendBufferSize();
> >> >> Any suggestions ?
> >> > 
> >> > 
> >> > 
> >> 
> > 
> > 
> > 
> 

Re: Maximum buffer

[pietry <pi...@death-squad.ro>]

Shouldnt the TCP/IP protocol handle this? The TCP specs say that it makes
sure all packets are delivered, no losses and no misorder...

The protocol can't be implemented response-based so there is nothing i can
do in this matter.. hoped there would be a way to make sure the packets are
received ok...


Jeroen Brattinga wrote:
> 
> That's common in TCP (and UDP) communications. Since you never really
> know how a packet is routed (one could be routed through Japan, the next
> through Russia, for instance), the order is something you have to keep
> track of. 
> 
> There are various ways to implement this (e.g. don't send a packet
> before you have received a packet), and it's one of the main things you
> have to keep in mind when implementing any network protocol!
> 
> 
> Jeroen Brattinga
> 
> On Sun, 2007-12-16 at 03:04 -0800, pietry wrote:
>> It works, thanks a lot :)
>> 
>> I also have another problem with TCP packages.. it seems that sometimes
>> they
>> reach in different order then i wrote to the Sessions. My question is :
>> is
>> this possible to be because of MINA or the settings i had to my server?
>> Or
>> it's a bug in my code ?
>> 
>> 
>> 
>> Jeroen Brattinga wrote:
>> > 
>> > You're propable using the TextLineDecoder? Then you have to set the
>> > maximum line length property (which defaults to 1KB). Use the
>> > setMaxLineLength method to do this.
>> > 
>> > Jeroen Brattinga
>> > 
>> > 
>> > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote:
>> >> I tried to increase the mina buffer sizes ( both receive and send) but
>> >> this
>> >> still has no success. I always get the same exception : 
>> >> buffer.org.apache.mina.common.BufferDataException: Line is too long:
>> 2954
>> >> (Hexdump: empty)
>> >> Used this getSessionConfig().setReceiveBufferSize();
>> >> and getSessionConfig().setSendBufferSize();
>> >> Any suggestions ?
>> > 
>> > 
>> > 
>> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14360895.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: Maximum buffer

[Jeroen Brattinga <je...@gmail.com>]

That's common in TCP (and UDP) communications. Since you never really
know how a packet is routed (one could be routed through Japan, the next
through Russia, for instance), the order is something you have to keep
track of. 

There are various ways to implement this (e.g. don't send a packet
before you have received a packet), and it's one of the main things you
have to keep in mind when implementing any network protocol!


Jeroen Brattinga

On Sun, 2007-12-16 at 03:04 -0800, pietry wrote:
> It works, thanks a lot :)
> 
> I also have another problem with TCP packages.. it seems that sometimes they
> reach in different order then i wrote to the Sessions. My question is : is
> this possible to be because of MINA or the settings i had to my server? Or
> it's a bug in my code ?
> 
> 
> 
> Jeroen Brattinga wrote:
> > 
> > You're propable using the TextLineDecoder? Then you have to set the
> > maximum line length property (which defaults to 1KB). Use the
> > setMaxLineLength method to do this.
> > 
> > Jeroen Brattinga
> > 
> > 
> > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote:
> >> I tried to increase the mina buffer sizes ( both receive and send) but
> >> this
> >> still has no success. I always get the same exception : 
> >> buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954
> >> (Hexdump: empty)
> >> Used this getSessionConfig().setReceiveBufferSize();
> >> and getSessionConfig().setSendBufferSize();
> >> Any suggestions ?
> > 
> > 
> > 
> 

Re: Maximum buffer

[pietry <pi...@death-squad.ro>]

It works, thanks a lot :)

I also have another problem with TCP packages.. it seems that sometimes they
reach in different order then i wrote to the Sessions. My question is : is
this possible to be because of MINA or the settings i had to my server? Or
it's a bug in my code ?



Jeroen Brattinga wrote:
> 
> You're propable using the TextLineDecoder? Then you have to set the
> maximum line length property (which defaults to 1KB). Use the
> setMaxLineLength method to do this.
> 
> Jeroen Brattinga
> 
> 
> On Sun, 2007-12-16 at 01:43 -0800, pietry wrote:
>> I tried to increase the mina buffer sizes ( both receive and send) but
>> this
>> still has no success. I always get the same exception : 
>> buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954
>> (Hexdump: empty)
>> Used this getSessionConfig().setReceiveBufferSize();
>> and getSessionConfig().setSendBufferSize();
>> Any suggestions ?
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14360544.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: Maximum buffer

[Jeroen Brattinga <je...@gmail.com>]

You're propable using the TextLineDecoder? Then you have to set the
maximum line length property (which defaults to 1KB). Use the
setMaxLineLength method to do this.

Jeroen Brattinga


On Sun, 2007-12-16 at 01:43 -0800, pietry wrote:
> I tried to increase the mina buffer sizes ( both receive and send) but this
> still has no success. I always get the same exception : 
> buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954
> (Hexdump: empty)
> Used this getSessionConfig().setReceiveBufferSize();
> and getSessionConfig().setSendBufferSize();
> Any suggestions ?