[Live-devel] RTSP server extending

[Gustaf Räntilä]

Igor Bukanov wrote:
> On 24/04/07, Gustaf Räntilä <opera at kth.se> wrote:
>   
>> Ross Finlayson wrote:
>>     
>>>> Actually there is problem here with sockaddr_in. It explicitly
>>>> excludes sockaddr_in6. It would better just to use sockaddr to
>>>> simplify IPV6 porting later.
>>>>
>>>>         
>>> The actual parameter to the call is a "sockaddr_in", so that's what I
>>> used for the formal parameter.
>>>
>>> There are many many places in the code that are IPv4-specific,
>>> unfortunately.  (The networking (groupsock) code will need to undergo
>>> a major restructuring before IPv6 could be supported...)
>>>       
>
> In this regard not passing sockaddr_in to specialClientAccessCheck was
> the right solution as getpeername returns the proper address. Note
> also that switching from sockaddr_in to sockaddr would also require to
> pass the address size parameter as otherwise IPv6-compatible code
> would be clattered with sizeof(sockaddr_ip), sizeof(sockaddr_ipv6).
>   
You obviosly didn't read the patch (and/or the second mail where I 
clarified my typo).
And not giving the sockaddr_in requires a new virtual function in your 
implementation, if you want programs to know when a client has 
disconnected, or how were you going to fix that? My patch handles this 
in the same function (and most people probably care for the sockaddr 
most and the file descriptor the least if at all).
>> Definition:
>> virtual Boolean sessionAccept(int clientSocket, const struct sockaddr*
>> clientAddr);
>>     
>
> The same arguments applies, one either passes just clientSocket or
> include clientAddrLength parameter.
>   
Again, read my mail. I use clientSocket for 2 things.
1: To _identify_ the session in subsequent calls with the other virtual 
functions (and the same, for disconnecting). You can't just take it away 
because you give the address as any sockaddr_xx.
2: It is useful for socket-level manipulations (setsockopt).

And the address length parameter _is_ there (and always was in the 
patch, again I'm sorry for the typo in my description).
>>  A program using liveMedia can never know/track what commands a
>> client are sending.
>>     
>
> The question: is client supposed to call DESCRIBE before calling any
> other commands within the same TCP session? If so the authentication
> bug is that the RTSPServer.cpp does not check for that.
>   
What? I just wrote, that it's not enough to trust that clients won't 
send PLAY after an "unauthorized" DESCRIBE. That's why I fixed it in the 
patch also. And obviously some clients _don't_ give a wuzz about 
DESCRIBE at all, so putting any trust in that is nuts. In my patch, the 
authorization function (with my session callback, or with the current 
user/pass class) is called from the other (critical) command functions.
>> Comment 2:
>> It is very difficult to follow the development of liveMedia and
>> cooperate by sending patches when there is no source code repository to
>> regularly update. Manually diffing the tar.gz tree is cumbersome.
>>     
>
> This is where quilt comes extremely handy,
> http://savannah.nongnu.org/projects/quilt . It allows to track tar
> with the same ease as one would use CVS/SVN etc.
>
>   
I will look into that, thanks for the hint!

Gustaf